JSON Formatter and Validator
Paste JSON and get it back indented, minified, or with its keys sorted. When it will not parse, you get a line and column number rather than a character offset, which is the difference between finding the problem and counting through four hundred characters by hand. An API response full of tokens and customer records is often what gets pasted here, which is why nothing is stored — it is formatted and discarded per request.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Two, four, tab, or minified output
- Syntax errors reported as line and column
- Recursive alphabetical key sorting that leaves array order alone
- Key count and nesting depth for the parsed document
How to use JSON Formatter
- 1
Paste the JSON
Anything the standard JSON parser accepts works — an API response, a config file, a log line. It parses shortly after you stop typing, so you do not press a button to find out whether it is valid.
- 2
Pick an indent
Two spaces is the common default and what most linters expect. Choose Minified instead to strip every space and line break for a config value or a query string.
- 3
Sort the keys if you are comparing
Turn on key sorting when you want to diff two documents that contain the same data in a different order. Arrays are deliberately left alone.
- 4
Copy or download
Copy the result, or download it as a .json file. The stats strip shows the key count and nesting depth, which is usually the fastest way to tell two similar payloads apart.
How it works
The parsing is JSON.parse, the same function your application will use. That is
a deliberate choice: a hand-written parser could give friendlier errors, but it
would also accept things the real one rejects, and a validator that is more
lenient than production is worse than no validator at all.
The interesting work is in what happens when the parse fails.
JSON.parse throws a SyntaxError, and the text of that error is not
standardized. Chrome and Node say Unexpected token } in JSON at position 42.
Newer versions say Expected ',' or '}' after property value in JSON at position 42 (line 3 column 5). Firefox says JSON.parse: expected ',' or '}' after property-value pair at line 3 column 5 of the JSON data. Safari frequently
reports no position whatsoever.
So the message is checked for a character offset first, because that form is exact and can be converted by counting newlines up to it. Failing that, an explicit line and column is read directly. Failing both, the engine's own text is shown with no location attached.
That last case is the one worth designing for. It is tempting to fall back to "line 1" or to the last line, and both are wrong in a way that costs real time — you go and stare at a line that is fine. Showing no line number is honest and sends you to the message instead.
Sorting, and the thing most formatters get wrong
Key sorting exists for one job: making two documents comparable.
An API that returns the same data with keys in a different order produces a diff where every line has changed and nothing has. Sorting both sides collapses that to the handful of values that actually differ.
The rule is that objects may be reordered and arrays may not. In the JSON data model an object is an unordered set of name/value pairs, so reordering it yields the same value. An array is ordered by definition, so reordering it yields a different one. A formatter that sorts arrays as well will make your diff look even cleaner, and it will also have changed your data.
When you'd use this
Reading an API response that arrived as one enormous line, which is the common case and the reason this tool exists.
Finding the syntax error in a config file that a deploy just rejected — the line and column here point at the same character the server choked on.
Minifying a JSON blob that has to go into an environment variable or a query parameter, where the whitespace is pure cost.
Comparing two payloads that should be identical, by sorting both and pasting them into a diff.
A note on numbers
One thing no formatter can fix: JSON numbers are parsed as IEEE-754 doubles, so an integer larger than 9,007,199,254,740,991 loses precision on the way in and comes back out as a different number. If you are handling 64-bit IDs from a database, they need to travel as strings. This tool will show you the rounded value faithfully, because that genuinely is what your application will see.
Examples
Sorting keys for a diff
Sorting is recursive, so the nested object is reordered too. This is the whole trick to diffing two API responses that carry identical data in a different key order — sort both and the diff collapses from every line to only the values that genuinely changed.
A duplicate key, which JSON quietly allows
The document is valid and the first value is gone. JSON permits repeated keys and every mainstream parser resolves them last-one-wins, silently. If a field keeps arriving with the wrong value from a service you do not control, this is worth checking before anything else — the key count in the stats strip reads 1, not 2.
Frequently asked questions
Is my JSON kept anywhere?
No. Parsing runs on this site's own server, so the JSON is sent over an encrypted connection to be formatted — but nothing is written to disk, logged, or retrievable afterward. It exists only for the moment it takes to produce the result, then the request ends and it is gone. That is worth being precise about, because the JSON people need to format is very often an API response containing bearer tokens, internal identifiers, or customer records.
Why does it show a line and column when the engine only reports a position?
Because a character offset is not usable by a human. JavaScript engines disagree about the message entirely — V8 (the engine behind Chrome and this site's own server) says "at position 42", older versions omit a line and column entirely, and other engines format it differently again. This tool reads whichever form it was given, converts an offset into a line and column by counting newlines, and shows only the engine's own text when it can recover no position at all rather than guessing at one.
Why are object keys sorted but arrays left in place?
Because sorting an array changes what the document means and sorting keys does not. The objects {"a":1,"b":2} and {"b":2,"a":1} are the same value by definition. The arrays [1,2,3] and [3,2,1] are two different values, and a tool that reorders them produces a clean-looking diff while corrupting the data. Several online formatters get this wrong.
Will it accept JSON5, comments, or trailing commas?
No, and that is intentional. This validates against the actual JSON specification, which has no comments and no trailing commas, so a file your editor tolerates may be rejected here. That is the useful answer: if it fails here it will fail in whatever service you were about to send it to. Configuration formats that look like JSON but permit extras need a parser for that specific dialect.
What do the depth and key counts mean?
Depth is how many levels of nesting the deepest value sits at, counting a top-level scalar as zero. Key count is every object key in the whole document including nested ones, so it goes up as you nest rather than only counting the top level. Both are there because they are the quickest way to tell whether two similar payloads are actually the same shape.
Further reading
- The Same Table Was Three Times Bigger as JSONCSV writes each column name once, at the top. JSON writes it again on every single row. On a table of any size that is not a subtlety — it is the dominant term, and it explains both why the conversion inflates and why it barely matters over the wire.
- Compressed, Base64 Cost Nothing on a JPEG and 17% on JSONBase64 costs a third, and almost everything it travels over is compressed, so the real question is what survives the compressor. The answer is not one number: on already-compressed data the overhead vanishes, and on compressible data a sixth of it stays.
- Minifying JSON Saved 36%, and 3.7% Once It Was CompressedMinifying JSON is standard advice and the raw saving is large enough to make it look obviously correct. Almost everything that carries JSON compresses it first, and once you measure the compressed sizes the case mostly disappears.