Formatting parses the document and prints it back, so the output is canonical rather than merely indented: escape sequences and number representation are normalised, and key order can be sorted. That makes two responses genuinely comparable in a diff, which the raw bytes from two servers usually are not.
Because it parses first, malformed input fails here rather than three services downstream, and the error carries the line and column of the offending character. If you only need the yes-or-no answer, the JSON Validator is faster to read; if you want indentation applied without touching anything else, use the JSON Beautifier.
Frequently asked questions
Is my JSON uploaded to a server?
No. The formatter runs entirely in your browser using JavaScript — your JSON never leaves the page and is never logged. You can confirm this by opening your browser devtools Network tab while formatting: there are no requests.
What indentation should I use for JSON?
Two spaces is the most common convention and the default here — it is what npm, Prettier and most style guides use for JSON. Four spaces is common in Python and .NET ecosystems. Tabs are valid JSON but rarer, because JSON is more often machine-read than hand-edited.
Why does the formatter reject my JSON?
JSON is stricter than JavaScript object literals. The four most common causes are: trailing commas after the last item, single quotes instead of double quotes, unquoted object keys, and comments — none of which are valid JSON. The error message includes the line and column so you can jump straight to the problem.
Does sorting keys change the meaning of my JSON?
No. The JSON specification defines an object as an unordered set of name/value pairs, so key order carries no meaning and sorting is a lossless operation. Array order, by contrast, is significant and is never touched.