About the JSON Formatter & Validator
This JSON formatter parses whatever you paste, tells you immediately whether it is valid, and hands back a readable version indented with 2 spaces, 4 spaces or tabs. If the document is broken you get the parser's own error message, which usually names the character position of the offending token. You can also minify, sort every object's keys alphabetically, and read a short structural summary showing key count, array count and nesting depth. Nothing is uploaded: the parse runs on the JSON engine already built into your browser, so pasting an API response full of customer records or internal identifiers carries no transmission risk.
How to use the JSON Formatter & Validator
- 1
Paste your JSON into the JSON box, replacing the sample object.
- 2
Pick an option under Output: beautify with 2 spaces, 4 spaces or tabs, or choose Minify to strip every optional byte.
- 3
Tick 'Sort keys alphabetically' if you plan to diff this document against another one.
- 4
Read the green validity note, then copy the formatted result or download it as data.json.
- 5
Check the Structure panel for key count, array count, maximum depth and how many characters minifying would save.
What people use it for
Reading an unformatted API response
Production APIs return JSON on a single line to save bandwidth. Beautifying it turns a 4,000-character blob into something you can actually scan for the field you are debugging.
Finding the syntax error in a config file
package.json, tsconfig.json and composer.json all reject trailing commas. Pasting the file surfaces the exact parse failure instead of a vague build error from your toolchain.
Making two payloads diffable
Sorting keys and using a fixed indent gives two structurally identical documents byte-identical text, so a diff shows only the values that genuinely changed.
Shrinking a payload before shipping
Minify seed data or a static fixture before committing it to a bundle, and use the savings figure to judge whether the change is worth making.
What the JSON grammar does and does not allow
JSON is specified by RFC 8259 and, identically, by ECMA-404. The grammar is deliberately tiny, and most parse failures come from developers assuming JavaScript object literal rules apply. They do not. Keys must be double-quoted strings, so a bare identifier such as name followed by a colon is invalid. Strings must use double quotes, never single quotes. Trailing commas after the last element of an object or array are forbidden, which is why appending a line to a hand-edited config so often breaks it. Comments were left out on purpose: Douglas Crockford removed them because people had started using them to carry parsing directives, which defeats the point of a neutral interchange format. That is why JSON with Comments, the dialect used by tsconfig.json and VS Code settings, is a separate non-standard format that a strict parser will reject. The only literals are true, false and null, all lowercase. NaN and Infinity are not JSON values, so a serialiser that emits them has produced something no conforming parser will read.
Numbers, key order and the limits of round-tripping
JSON numbers have no declared precision, but every mainstream parser reads them into an IEEE 754 double. That gives exact integers only up to 2^53 - 1, or 9,007,199,254,740,991. Snowflake identifiers and 64-bit database keys exceed that, and they silently lose their last digits on parse. The standard workaround is to transport such values as strings. Similarly, 1.0 and 1 both become the same double, so re-serialising may not return the text you started with. Key order is the second thing that does not survive a round trip: RFC 8259 describes an object as an unordered collection, and although most parsers preserve insertion order in practice, no code should depend on it. That is precisely why sorting keys is a safe normalisation — it changes nothing semantically while making two documents comparable line by line. Duplicate keys are the third trap: the specification calls them undefined behaviour, and JavaScript quietly keeps the last one.
Tips
- If the parser complains about position 0, check for a UTF-8 byte order mark or a stray HTML error page ahead of the JSON.
- Keep formatted JSON in Git and minify at build time — line-based diffs are useless on a single-line file.
- A maximum depth above six or seven usually means the schema wants flattening before it reaches a client.