Json Validator

JSON Validator

Paste JSON into the box, or open or drag in a file up to 10 MB. It’s checked as you type.

If something’s wrong, you get the exact line and column, the mistake highlighted in context, and a button to jump straight to it. The most common mistakes come with a plain-language explanation and the fix.

If it’s valid, you can format it with 2 spaces, 4 spaces or tabs, or minify it. Then copy the result or download it.

Validation runs in your browser, so nothing you paste leaves your computer.

Example: a comma too many

{
  "name": "Maria",
  "roles": ["admin", "editor",],
  "active": true
}

The validator points to line 3, where the list ends with a comma before the closing ]. JSON doesn’t allow a comma after the last item, so remove it. JavaScript code does allow trailing commas, which is why this is the most common mistake in JSON written by hand.

Compare that with what a browser says about the same text:

Unexpected token ']', "{"a":[1,2,],"b":1}" is not valid JSON

No line, no column, and no hint about the real problem, which is the comma.

Common mistakes and how to fix them

Two sources cause most of these:

• Python output. print() on a dictionary uses single quotes and True/None, so it isn’t JSON. Use json.dumps() instead.
• JavaScript objects copied from code. These often have unquoted keys, single quotes and trailing commas, all of which JavaScript accepts and JSON doesn’t.

Invisible problems

Some errors can’t be seen in the text at all. The validator finds and marks them:

• A byte order mark (BOM) at the very start of the file. Some Windows editors add it. JavaScript’s JSON.parse rejects the whole file because of it, and Python stops with “Unexpected UTF-8 BOM.”
• No-break spaces. They look like ordinary spaces, but JSON allows only regular spaces, tabs and line breaks between values. They come in when you copy from web pages, Word, email or chat apps.
• Curly quotes (“ ” instead of “). Word, Google Docs, and autocorrect on phones and Macs swap them in without asking.
• A line break inside a string. Text in quotes has to stay on one line, with line breaks written as n. This happens when multi-line text is pasted into a value.

Valid JSON that can still cause trouble

Some JSON passes every syntax check and still leads to bugs. The validator adds a note when it finds these:

Duplicate keys. {"id": 1, "id": 2} is valid, but programs disagree on what it means. JavaScript and Python keep the last value, so id is 2. Other parsers keep the first, and some reject it. When two systems read the same file differently, they end up acting on different data.

Integers too large to store exactly. JavaScript can’t hold whole numbers above 9,007,199,254,740,991 precisely, so it reads 9007199254740993 as 9007199254740992. No error is raised; the number just changes. That’s why many APIs send long IDs as strings.

Broken emoji escapes. An emoji can be written as two escape codes, like "ud83dude00" for 😀. If only the first half is present, "ud83d", the JSON is still valid, but it isn’t a real character. Some programs reject it, and others turn it into the � symbol.

Very deep nesting. Objects inside lists inside objects, hundreds of levels down, are valid. But many parsers set a limit. PHP’s json_decode stops at 512 levels by default, and Ruby’s JSON parser at 100.

Backslashes in Windows paths. This one the validator can’t flag, because the JSON is perfectly valid. "C:newfolder" doesn’t mean what it looks like: n is read as a line break and f as a form feed, so the path comes out as “C:”, a line break, “ew”, an invisible character and “older”. Write "C:\new\folder" or use forward slashes.

Formatting and minifying without changing values

Format adds line breaks and indentation so the structure is easy to read: 2 spaces, 4 spaces or tabs. Minify removes all of that to make the file as small as possible for sending or storing.

Neither one changes a single value. That matters more than it sounds. Most online formatters read the JSON into JavaScript and print it back out, which quietly changes the data. This:

{"id": 9007199254740993, "price": 1.50, "size": 1e3, "id": 2}

comes back from a typical JavaScript-based formatter as:

{"id": 2, "price": 1.5, "size": 1000}

The first id is gone, 1.50 lost its zero, and 1e3 was rewritten. This validator keeps every value exactly as you wrote it.

JSON Lines mode

Log files and many data exports use JSON Lines, also called NDJSON: one complete JSON value per line, with no surrounding brackets.

{"level": "info", "msg": "Server started"}
{"level": "error", "msg": "Disk full"}

In normal mode this is reported as invalid, because a JSON file can contain only one value. Switch to JSON Lines mode and each line is checked on its own, with errors reported by line number.

FAQ

Can JSON have comments?

No. Files like tsconfig.json and VS Code’s settings.json use a variant called JSONC that allows comments, so they’ll show errors here. That’s expected, and those programs read them fine.

My JSON is valid, but my app still rejects it. Why?

The validator checks syntax, not content. Your app may expect certain fields, types or values, and that’s a separate check, usually done with JSON Schema. For schema.org structured data, the JSON-LD Validator checks both.

How large a file can I check?

Up to 10 MB. Open it with the file button or drag it onto the page.

What’s the difference between this and the JSON Viewer?

The validator finds and explains errors. The JSON Viewer shows valid JSON as a tree you can expand and collapse. To convert JSON into a spreadsheet, use JSON to CSV.

Is my JSON sent anywhere?

No. Everything runs in your browser, and nothing you paste or open is uploaded.