JSON is a strict format that looks forgiving, which is why so much time gets lost to it. A formatter does two jobs: it makes a wall of minified text readable, and it tells you precisely where the parser gave up. The second job is usually the one you came for.
The four things JSON does not allow
Most parse failures are one of the same four mistakes, all of them things that are perfectly legal in JavaScript and illegal in JSON. Trailing commas after the last element. Single quotes instead of double quotes. Unquoted keys — {name: "x"} is a JavaScript object literal, not JSON. And comments, which the format has never supported at any point in its life.
That last one catches people configuring tools. If a config file accepts comments, it is not JSON — it is JSON5 or JSONC, formats that look identical until a strict parser refuses to read them. The values NaN and Infinity are out too, which is why serialising the result of a division can produce something no parser will take back.
Formatting can silently reorder your keys
This surprises people, and it is worth knowing before you paste a file back into production. Any tool that formats JSON parses it into memory and re-serialises it. For ordinary string keys that round-trip preserves insertion order, so nothing moves. But keys that look like non-negative integers are special: JavaScript enumerates those first, in ascending numeric order, no matter where they sat in your file.
So {"10":"a","2":"b","name":"c"} comes back as {"2":"b","10":"a","name":"c"}. The data is identical and every parser will agree, but a line-by-line diff will light up. If you are formatting a file that is under version control and keyed by numeric IDs, expect that noise.
Large integers lose precision, quietly
This one causes real bugs in production. JSON has no integer type — it has numbers, and JavaScript represents every number as a 64-bit float. That gives you exact integers only up to 9007199254740991, which is 2^53−1. Past that, values are silently rounded to the nearest representable one.
Paste {"id":9007199254740993} into any browser-based JSON tool and it will hand you back 9007199254740992. Nothing errors. Nothing warns. The ID is simply wrong now. This is why APIs that deal in large identifiers — Twitter/X, Discord, database snowflake IDs — send them as strings. If your JSON contains IDs beyond that range as bare numbers, do not round-trip it through any JavaScript tool, this one included.
Minifying is worth less than you think
Stripping whitespace from JSON typically cuts 10–20% of the raw size, which sounds useful until you remember that your server almost certainly serves it gzipped or brotli-compressed. Compression algorithms are extremely good at repetitive whitespace — it is close to free to them. After compression the difference between formatted and minified JSON is often a couple of percent.
Minify when you are embedding JSON in a URL, a data attribute, or somewhere it will not be compressed. For an API response over HTTP, readability in the network tab is usually worth more than the bytes.
Common questions
Is my JSON sent to a server?
No. This tool is marked "client": parsing and formatting run in your browser tab, and the text never leaves your machine. That said, JSON pasted from a real system often contains tokens, customer records or internal identifiers — if that is your case, use an editor your organisation controls rather than any free web page, including this one.
The error says "position 1247" — how do I find that?
The number is a character offset from the start of the input, not a line number, which makes it awkward to use by hand. Format the document first: once it is indented, the parser reports the failure against a readable structure and the offending line is usually obvious. It is also worth knowing that the reported position is where the parser noticed the problem, not always where you made it — a missing closing brace is often reported far below the line that is actually wrong.
Does formatting change my data?
Almost never, but "almost" hides two cases. Numeric-looking keys get reordered, and integers beyond 2^53−1 lose precision — both explained above. Everything else round-trips byte-for-byte in meaning, even if the whitespace differs.
Can I use comments in a JSON config file?
Not in JSON itself. If your tool accepts them it is reading JSONC or JSON5, or it is stripping the comments before parsing. Many editors will happily let you write them and a strict parser downstream will then reject the file, which is a confusing failure to debug. If you need to annotate a JSON document and cannot change the format, a conventional workaround is a sibling key such as "_comment".
What happens with duplicate keys?
The specification says names "should" be unique but does not forbid repeats, so behaviour is up to the parser. In practice JavaScript takes the last occurrence and discards the earlier ones without any warning. If a document has duplicates, formatting it here will collapse them to one — which is a change you may not want, so check before pasting the result back.