JSON Validator: Stop Hunting for That Missing Comma
If you've spent twenty minutes staring at a config file trying to find a syntax error, a JSON validator would have told you the exact line in two seconds.
JSON is deceptively simple. Objects, arrays, strings, numbers, booleans, null — that's the whole spec. But it's strict in ways JavaScript isn't: keys must be double-quoted, trailing commas are illegal, and comments don't exist. These rules trip up everyone, especially when hand-editing config files or debugging API responses.
This tool parses your input, tells you exactly where it breaks, and pretty-prints the result if it's valid. No signup, no install — just paste and go.
What's actually happening
The tool runs your input through a JSON parser (the same JSON.parse() your code uses). If it fails, you get the error location — line and column. If it succeeds, the output is re-serialized with 2-space indentation so you can actually read it.
No schema validation, no type checking. Just: is this valid JSON or not?
Using it
Paste your JSON. If it's valid, you get pretty-printed output. If it's broken, you get the error with its location. Hit Copy to grab the formatted result. Clear or Ctrl+K to reset.
When you'd actually reach for this
- You got a malformed API response from a third-party service and need to figure out where it breaks
- You're editing
package.jsonortsconfig.jsonby hand and want to check before committing - You copied minified JSON from a browser network tab and need it readable
- You're about to paste a payload into Postman or a
curlcommand and want to verify it first - You're debugging a config file for AWS CloudFormation, Docker Compose, or ESLint
The five JSON mistakes everyone makes
These account for like 90% of validation failures:
Trailing commas — valid in JavaScript, illegal in JSON:
{ "name": "alice", "age": 30, }
Single quotes — JSON requires double quotes, no exceptions:
{ 'name': 'alice' }
Unquoted keys — every key must be a double-quoted string:
{ name: "alice" }
Comments — JSON has no comment syntax. At all:
{ "debug": true // enable debug mode }
Missing commas — easy to miss when you're adding fields:
{ "name": "alice" "age": 30 }
If your JSON won't parse and you can't see why, it's almost always one of these.
Why not just use JSON5 or JSONC?
Fair question. If JSON is this strict, why not use something more forgiving?
JSON5 adds single-quoted strings, unquoted keys, trailing commas, comments, multi-line strings, hex numbers. It's closer to JavaScript object literals. Some build tools support it.
JSONC is JSON plus // and /* */ comments. VS Code uses it for settings.json and tsconfig.json. It's not a formal spec — just JSON with a comment-stripping step.
Plain JSON is the universal format. Every language, every parser, every API supports it. JSON5 and JSONC are great for config files humans edit. For data interchange, stick with JSON — it's the one format where you'll never have a compatibility problem.
Troubleshooting
The error says "unexpected token" but I can't see anything wrong — check for invisible characters. Copy-pasting from rich text editors, PDFs, or Slack can introduce zero-width spaces, smart quotes ("" instead of ""), or em dashes. Paste into a plain text editor first.
"Unexpected end of JSON input" — your JSON is truncated. You're probably missing a closing } or ]. Count your opening and closing brackets.
The error points to a line that looks fine — the actual mistake is usually on the line above. A missing comma after a property causes the parser to choke on the next line.
My JSON has a BOM (byte order mark) — some editors prepend \uFEFF to files. The JSON parser sees it as an unexpected character at position 0. Strip it.
Everything validates but my code still can't parse it — check encoding. If the file is UTF-16 and your parser expects UTF-8, it'll fail silently or produce garbage.
Things that are valid JSON but might surprise you
A bare string is valid. "hello" is a complete JSON document. So is 42, true, and null. A JSON document doesn't have to be an object or array — though almost every API returns one of those.
Duplicate keys are technically allowed. { "a": 1, "a": 2 } parses without error in most implementations. The spec says behavior is undefined for duplicate keys — some parsers keep the last value, some keep the first. Don't rely on this.
Numbers can be weird. 1e100 is valid JSON. So is -0. But NaN, Infinity, and leading zeros (01) are not. If you're serializing JavaScript objects with these values, they'll be silently converted to null.
Empty objects and arrays are fine. {} and [] are valid. [{}] is valid. [[[[]]]] is valid. They're all legal, just probably not what you meant.
What to do with the output
Copy the pretty-printed JSON back into your config file, API request, or code. If you found an error, fix it in the source — don't just fix the copy.
For ongoing validation, set up a linter in your editor. VS Code validates JSON files by default. For CI, jq . < file.json > /dev/null fails on invalid JSON with a nonzero exit code.