JSON Formatter
Format, validate, sort, and minify JSON with syntax highlighting.
How to find the error in invalid JSON
Paste the document above and the parser reports the first position it could not read. That position is where parsing stopped, which is usually one or two characters after the mistake itself: a missing comma is reported at the start of the next key, not at the end of the previous value. Read backwards from the reported offset rather than staring at it.
Almost every invalid JSON document fails for one of a handful of reasons:
| Mistake | Looks like | Why it is invalid |
|---|---|---|
| Trailing comma | [1, 2, 3,] | Legal in JavaScript, never legal in JSON |
| Single quotes | {'id': 1} | JSON strings require double quotes, keys included |
| Unquoted key | {id: 1} | Valid JavaScript object literal, invalid JSON |
| Comment | // note | JSON has no comment syntax at all |
| NaN or Infinity | {"x": NaN} | Not JSON number literals; serialisers emit them by mistake |
| Unescaped control character | A literal newline inside a string | Must be written as an escape sequence |
| Wrapped in a callback | cb({...}) | That is JSONP, not JSON |
A special case worth knowing: a response that begins with a byte order mark or with stray whitespace from a logging wrapper will fail to parse while looking perfectly fine on screen. If the document looks correct and still will not parse, suspect an invisible character at position 0.
Reading an API response you did not write
Most API responses arrive minified: one line, no whitespace, impossible to scan. Formatting restores the structure so you can see nesting depth, spot which fields are arrays rather than objects, and check whether a field you expected is missing or merely null. Those two are different defects and a minified payload hides the difference.
When writing assertions against a response, format it first and work out the exact path to the value you care about. Guessing at a path from a minified string is how tests end up asserting on the wrong element of the wrong array.
When to minify instead of format
Minify when the JSON is going into something that counts bytes or dislikes newlines: a request body in a load test, a single-line environment variable, a value pasted into a CI configuration field, or a fixture you want to keep to one line so diffs stay readable. Format when a human has to read it. Both operations are lossless, the parsed value is identical, so you can move between them freely without changing what your test sends.
Comparing two JSON responses
Format both documents with the same indentation first, then diff them. Without that step a diff tool reports every line as changed simply because one side was minified. Be aware of two traps that make a meaningless diff look alarming: object key order is not significant in JSON but most diff tools treat it as significant, and array order usually is significant, so a reordered list is a real change even when the set of elements is identical.
Validating a JSON fixture before it reaches your test suite
- Paste the fixture and confirm it parses at all: a broken fixture fails a test for a reason unrelated to the product.
- Format it and check the shape matches what the endpoint actually returns, including nesting.
- Look for values a serialiser may have mangled: numbers rendered as strings, large integers that lost precision, dates in an unexpected format.
- Minify it if it needs to live on one line, and store the formatted version alongside for review.
All of this happens in your browser. Response bodies from a staging environment often contain real customer data, so a formatter that does not upload the document is the right default rather than a nicety.
Frequently asked questions
Why does my JSON fail to parse when it looks correct?
The three usual causes are an invisible character such as a byte order mark at the start, a trailing comma left by an editor, and smart quotes introduced by pasting through a word processor or chat client. All three are invisible in most editors and all three are fatal.
Does formatting JSON change its meaning?
No. Whitespace between tokens is not significant in JSON, so formatting and minifying produce the same parsed value. The one thing to watch is that formatting does not fix key order, and it does not make an invalid document valid: it only reveals where the problem is.
What is the difference between JSON and a JavaScript object?
JSON is a strict text format: double-quoted keys and strings, no comments, no trailing commas, no functions, no undefined, no NaN. A JavaScript object literal allows all of those. Most invalid JSON is valid JavaScript, which is exactly why the mistakes are hard to see.
How do I handle large numbers in JSON?
Carefully. JSON numbers have no defined precision limit, but most parsers read them as IEEE 754 doubles, so an integer above roughly nine quadrillion loses precision silently. APIs that use 64-bit identifiers should send them as strings, and a test that checks an id survives a round trip is worth having.
Is it safe to paste an API response into an online formatter?
Only if the formatter does not transmit it. Staging and production responses routinely contain names, emails, tokens and internal identifiers. This formatter parses the document in your browser and sends nothing, which you can confirm in the DevTools Network tab.
What does a JSON validator check that a formatter does not?
Syntax validation confirms the document parses. It does not confirm the document is correct for your API: that requires JSON Schema validation against a contract, which checks required fields, types and value constraints. Passing a syntax check is necessary, not sufficient.