JSON was designed to be human-readable, yet most of the JSON you actually meet is a few thousand characters crushed onto one line. This tool expands that blob so its structure is visible, minifies it again when you are shipping it, and — most usefully — tells you the exact line and column where the syntax breaks.
Computing that error position ourselves is what sets this apart from a plain formatter. Browsers disagree wildly about what JSON.parse reports: recent Chrome drops the position entirely, Firefox gives a line and column, and Safari gives nothing at all. So this tool walks the input against the RFC 8259 grammar and finds the first place it stops being valid, which means you get the same answer in every browser.
How to use
- Paste your JSON — Drop JSON into the left pane — a one-line API response or a multi-line config file, either works. Valid input is formatted on the right immediately, with counts of objects, arrays, keys and the maximum nesting depth underneath.
- Pick an indent — Choose two spaces, four spaces, tabs, or minify to strip whitespace entirely. When minifying, a badge shows how much smaller the result is, so you can see straight away whether trimming a payload is worth it.
- Sort keys to compare two payloads — Turn on sort keys alphabetically to normalise object key order. This is the fastest way to diff two responses from the same API when only the key order differs and the diff is otherwise unreadable. Arrays are left alone, since their order carries meaning.
- Look up a path — Type something like
items[0].skuinto the path box to pull out just that value. If the path stops resolving partway, the tool tells you how far it got — handy for checking whether you misremembered a field name deep inside a nested response.
Frequently asked questions
Does it accept JSON with comments (JSONC)?
No. Comments, trailing commas and unquoted keys are all invalid JSON and will be reported as errors.
Files like tsconfig.json and VS Code settings use JSONC, a separate dialect that permits comments. Strip them before pasting. Trailing commas are flagged at their exact position, so it is obvious which one to delete.
My numbers change slightly after formatting.
JSON numbers are parsed into JavaScript double-precision floats, so any integer above 2^53 (about 9 quadrillion) loses precision. Old Twitter snowflake IDs are the classic example — the last few digits come back different.
This is a limitation of JSON.parse itself rather than this tool; you get the same result typing it into the browser console. Most APIs that deal in large integers know this and send IDs as strings. If you are designing an API, do the same.
When would I use "escape to string"?
When you need to embed JSON inside other code as a string literal — a test fixture, a curl -d argument in a shell script, or a log format that nests JSON inside a JSON field.
Unescape goes the other way: paste something like {\"user\":{\"id\":1}} copied out of a log and get real JSON back. Switch to format mode afterwards to see its structure.
How large a file can it handle?
A few megabytes is comfortable. Everything runs on the browser's main thread, though, so a file in the tens of megabytes will freeze the tab while it formats.
For large dumps, a CLI tool suits better: jq . input.json to format and jq -c . to minify. This tool is built for looking at one response quickly.
Concepts worth knowing
What JSON does not allow
JSON is stricter than it looks. Keys must use double quotes, single quotes are never valid, and a comma after the last element is an error. NaN, Infinity and undefined are not values, and numbers cannot have a leading zero like 01.
The confusion comes from how closely it resembles a JavaScript object literal without being one. Copying notation that works in code into a .json file is a common way to break a parse, and almost every error this tool points at is one of those five.
Why error messages lost their positions
Older V8 (Chrome, Node) said Unexpected token } in JSON at position 42. Recent versions changed to Unexpected token '}', "{\"a\": }" is not valid JSON — dropping the offset and quoting a fragment instead. That is friendlier for short input and considerably worse for a large document.
So any tool that needs a real position parses the input itself rather than trusting the engine. This one walks values, objects, arrays, strings and numbers in order, finds the first offset that violates the grammar, and converts it to a line and column.
How much minifying actually saves
Stripping indentation typically removes 15–30% of the characters. But real HTTP responses are usually sent gzipped or brotli-compressed, and repeated whitespace is exactly the pattern those algorithms handle best — so the difference over the wire is smaller than the character count suggests.
Minifying pays off elsewhere: storage with hard quotas like localStorage, WebSocket messages that skip compression, and APIs that bill per character of request body. Config files committed to Git, on the other hand, are far easier to review when left formatted.