How to format JSON
- Paste your JSON into the box above, minified, messy or already formatted.
- Pick the indentation your project uses. Two spaces is the most common convention.
- Read the summary line, which confirms the JSON is valid and describes its shape.
- If there is an error, jump to the line and column reported and fix it.
- Copy the formatted result, or download it as a .json file.
What this formatter does
- Indents with 2 spaces, 4 spaces or tabs, whichever your project uses.
- Reports the exact line and column of a syntax error, not just a character offset.
- Explains common mistakes in plain language, trailing commas, single quotes, missing braces.
- Summarises the structure: key count, object and array counts, and nesting depth.
- Preserves key order exactly as it appeared in the source.
- Runs live as you type, with nothing uploaded to a server.
Why formatting is the first debugging step
An API response arrives as one enormous line. Somewhere in it a field is missing, or a value is a string where a number was expected, or an array is empty when it should not be. Reading that as a single line is close to impossible, which is why formatting is almost always the first thing anyone does with unfamiliar JSON.
Indentation turns structure into something the eye can follow. Nesting becomes visible as depth, sibling keys line up, and an array of objects reads as a list rather than a wall. The data has not changed at all, only its presentation.
The mistakes that break JSON
- Trailing commas. Valid in JavaScript, invalid in JSON. The commonest error by a distance.
- Single quotes. JSON requires double quotes on every string and every key.
- Unquoted keys.
{name: "x"}is a JavaScript object literal, not JSON. - Comments. JSON has none. A
//line will fail to parse. - Undefined and NaN. Neither exists in JSON. Use null, or omit the key.
Every one of these produces a terse engine message that names a character offset nobody can find. This tool converts that offset into a line and column and says what the problem actually is.
Reading the structure summary
Alongside the formatted output you get a count of keys, objects and arrays, and the maximum nesting depth. Depth is the number worth watching. Anything beyond five or six levels is hard to work with in code, and often indicates a structure that would be easier to consume if it were flattened.
The key count is a quick sanity check against what you expected. If an API is documented as returning twelve fields and the count says nine, three are missing before you write a line of code to look for them.
Formatting does not change the data
Worth stating because people worry about it. Whitespace between tokens is insignificant in JSON, so a formatted document and its minified equivalent parse to exactly the same value. Key order is preserved here, although the specification treats objects as unordered, do not rely on order in code, but it is helpful to keep it when you are comparing two versions of a document by eye.
Numbers are the one thing that normalises. Re-serialising turns 1.50 into 1.5 and 1e3 into 1000, because those are the same number. If exact numeric formatting matters, that is a sign the value should have been a string.
What to do next
Once the JSON is readable, the JSON validator gives a fuller error report with surrounding context when something is still wrong. The JSON minifier reverses this operation for production use, and the JSON beautifier adds alphabetical key sorting when you are comparing two documents.
Everything happens in your browser, so API responses containing customer data, tokens or internal identifiers are never uploaded anywhere.