PRACTICAL GUIDE
How to Format and Validate JSON Quickly
Reading an unreadable API response, finding the character that actually broke it, and knowing which JSON-like things are not JSON at all.
Last updated
Formatting and validating are not the same thing
Pretty-printing adds indentation and line breaks so a human can see the structure. Validation answers a different question: is this legal JSON at all. A tool that reformats broken input without complaining has told you nothing, and a tool that reformats it into something that parses has quietly changed your data.
In practice they arrive together, because a parser has to succeed before anything can be re-printed. If the formatter refuses, that refusal is the useful output.
The things that look like JSON and are not
A JavaScript object literal is the usual culprit. JSON requires double quotes around both keys and string values, forbids a trailing comma after the last item, and has no comments. Copy an object out of a source file and all three will be waiting for you.
The others are undefined, which JSON has no concept of, and NaN or Infinity, which are not valid numbers. Single quotes are the most common of all, and the easiest to miss when the string itself contains an apostrophe.
Reading the error instead of hunting
A parser reports the position where it gave up, which is almost never where the mistake is. A missing closing brace is reported at the end of the file; a missing comma is reported at the start of the next key. The useful habit is to read the reported position and then look backwards for the last thing that was structurally complete.
Minifying, and what it is actually worth
Whitespace is for people. Removing it shrinks a payload, though usually less than expected once the transport compresses it, since indentation compresses extremely well. Minify for storage and for wire formats where compression is not applied; do not minify a configuration file that a human has to edit, where the readability is worth far more than the bytes.
Be careful what you paste
The JSON people need to format is usually a real API response, and real API responses carry bearer tokens, session identifiers, email addresses and account numbers. Pasting one into an unknown website hands all of that to whoever runs it. Our formatter parses the text in your browser and never sends it anywhere, which is the only property that makes this safe to do casually.
Frequently asked questions
Is my JSON sent anywhere?
No. It is parsed and re-printed in your browser, and the analytics on the page record that a tool was used rather than anything about the content. That is the point: the whole reason to format JSON is that it came from somewhere real.
Why does my JSON fail when it works in JavaScript?
Because JavaScript object literals are not JSON. Single quotes, unquoted keys, trailing commas, comments and values like undefined are all legal in a source file and all rejected by a JSON parser. Those five account for nearly every failure of this kind.
Are duplicate keys valid?
The specification allows them and says nothing about what should happen, so parsers differ; most keep the last one silently. Treat a duplicate key as a bug regardless of whether the file parses, because two readers can legitimately disagree about the value.
Does formatting change my data?
It should not change any value. It can change the order of nothing and the appearance of everything: whitespace, and sometimes how numbers are printed, since a parser that reads a very large number into a floating point value cannot always write it back identically. If exact numeric text matters, keep such values as strings.