JSON Formatting Guide: How to Format, Read and Debug JSON

Formatting JSON means adding line breaks and indentation so a person can see its structure. It sounds trivial until you are staring at a 4,000-character API response on a single line and trying to find one nested value. This guide covers how to format JSON with our JSON Formatter, how to choose an indentation size, how to read the error messages when formatting fails, and the part most guides skip: the few things a browser-based formatter can silently change in your data.

Every example below was actually run. Error messages come from a current Chromium-based engine (V8); Firefox and Safari word some of them differently, but the underlying problems and fixes are the same.

What formatting actually does

In principle, formatting only changes whitespace: the keys, values and structure of a formatted document are identical to the minified one, and both parse to the same data. That is the mental model most people have, and it is almost right.

The catch is how browser-based formatters work. They do not just insert spaces into your text. They parse the JSON into an in-memory object and then write it back out with the indentation you chose (in JavaScript, JSON.parse followed by JSON.stringify). That round trip is what makes it possible to reject invalid JSON with a precise error, but it also means the output is a re-serialisation of your data, not a copy of your text. The section What formatting can silently change shows exactly where that matters.

How to format JSON, step by step

1. Paste your JSON into the JSON Input box. Minified, messy or already formatted all work.
2. Pick an indent size from the dropdown (1, 2, 3 or 4 spaces).
3. Click Format JSON, or press Ctrl+Enter (Cmd+Enter on a Mac) while the cursor is in the input box.
4. Read the Formatted Output. If the JSON is invalid, a red message explains why instead (see Fixing the errors).
5. Click Copy Output to put the result on your clipboard.

Here is the input used in the screenshot, and the result:

{"user":{"id":1042,"name":"Ada Lovelace","roles":["admin","editor"],"active":true,"address":null}}

{
  "user": {
    "id": 1042,
    "name": "Ada Lovelace",
    "roles": [
      "admin",
      "editor"
    ],
    "active": true,
    "address": null
  }
}

Each run is added to Process History (Local). The last 20 runs are kept in your browser's local storage (inputs are truncated to 500 characters and outputs to 2,000 in the saved copy), you can click an entry to restore it, and Clear All wipes the list. Nothing in the history is sent anywhere, but on a shared computer it is worth clearing.

Choosing an indentation size

Indentation is purely a readability choice; it does not change the data. The same 98-character one-line example above becomes 135 characters with 1-space indentation, 155 with 2 spaces, 175 with 3 and 195 with 4. The difference is only whitespace, but on deeply nested documents it adds up in how much fits on screen.

• 2 spaces is the common default in JavaScript and many web projects, and keeps deeply nested structures narrow.
• 4 spaces makes each nesting level easier to tell apart at a glance and is common in other ecosystems.
• Whichever you pick, match your project's existing style (editor config or linter) so formatted snippets paste cleanly into the codebase and diffs stay small.

If you need the opposite, a compact one-line version for a request body or a config value, use the JSON Minifier.

How to read formatted JSON

Once the structure is visible, JSON has only a few shapes. Curly braces { } hold key-value pairs, square brackets [ ] hold ordered lists, and values are strings, numbers, true, false, null, or more objects and arrays. Indentation shows depth, and a closing bracket lines up with the line that opened it, so you can collapse a block mentally by finding its matching bracket.

In the example above, the value "editor" lives at user.roles[1]: inside user, inside roles, second item (counting from 0). That path notation is how most tools and libraries address a value. To test paths against a real document, the JSONPath Tester is built for that, and the JSON Viewer / Tree Editor lets you collapse and expand branches.

Fixing the errors the formatter reports

When the input is not valid JSON, the tool shows Invalid JSON: followed by the message from the browser's parser, and nothing is formatted. If the box is empty you get Please enter JSON before processing instead. The messages include a character position (counted from 0) and, in current Chromium browsers, a line and column, which is usually enough to jump straight to the problem. These are the ten problems we see most, with the exact message produced for each.

• Trailing comma — {"a":1,"b":2,} gives Expected double-quoted property name in JSON at position 13 (line 1 column 14). JSON does not allow a comma after the last item. Delete it.
• Single quotes — {'a':1} gives Expected property name or '}' in JSON at position 1 (line 1 column 2). Keys and strings must use double quotes.
• Unquoted key — {a:1} gives the same message as single quotes. Valid JavaScript object literals are not automatically valid JSON; wrap the key in double quotes.
• Comments — {"a":1 /* note */} gives Expected ',' or '}' after property value in JSON at position 7. Standard JSON has no comments. Remove them (formats like JSONC and JSON5 allow them, but this tool follows the JSON standard).
• Missing comma — {"a":1 "b":2} gives the same Expected ',' or '}' message, pointing at the spot where a comma belongs.
• NaN or undefined — {"a":NaN} gives Unexpected token 'N', "{"a":NaN}" is not valid JSON, and undefined behaves the same. Neither exists in JSON; use null or omit the key.
• Leading zeros — {"a":012} gives Unexpected number in JSON at position 6. Numbers cannot start with 0 unless they are exactly 0 or a decimal such as 0.5. If it is an identifier (a ZIP code, for instance), make it a string.
• Unclosed structure — {"a":[1,2 gives Expected ',' or ']' after array element in JSON at position 9. Something was cut off, often when copying from a truncated log. Add the missing brackets.
• Extra text after the value — {"a":1} extra gives Unexpected non-whitespace character after JSON at position 8. Common when you paste a log line with a prefix, or two objects back to back. JSON allows only one top-level value.
• Raw tab inside a string — a real tab character in "x y" gives Bad control character in string literal in JSON at position 7. Control characters must be escaped, for example as \t.

If you only want a yes/no check without reformatting, the JSON Validator is the lighter option.

What formatting can silently change

Because the formatter re-serialises your data (see above), a handful of values can come out different from how they went in. None of this is specific to our tool; it is how JSON handling works in JavaScript, so any browser-based formatter behaves this way. We ran each case.

Input:  {"id":12345678901234567890,"price":1.10,"n":1e3,"z":-0,"f":1.0,"s":"é"}
Output: {"id":12345678901234567000,"price":1.1,"n":1000,"z":0,"f":1,"s":"é"}

• Large integers lose precision. JavaScript numbers are accurate only up to 9,007,199,254,740,991. 12345678901234567890 came out as 12345678901234567000, and 9007199254740993 as 9007199254740992. If your IDs are that large (some databases and social platforms use 64-bit IDs), they should travel as strings.
• Number formatting is normalised. 1.10 becomes 1.1, 1.0 becomes 1, 1e3 becomes 1000 and -0 becomes 0. The values are equal, but the text is not.
• Duplicate keys collapse. {"a":1,"b":2,"a":3} became {"a":3,"b":2}: the later value wins and the duplicate disappears without a warning.
• Number-like keys can move. {"b":1,"2":2,"a":3,"1":4} became {"1":4,"2":2,"b":1,"a":3}, because JavaScript lists integer-like keys first, in ascending order.
• Escapes are resolved. é is written back as the character é. Same data, different text.

The practical rule: use a formatter to read JSON, and keep the original text when exact bytes matter, such as a signed payload, a hash, or a file you will commit unchanged. If you need to compare two versions, format both with the same indent size and put them through Text Compare so only real differences show up.

Is it safe to paste JSON into an online formatter?

For this tool, formatting happens in your browser. We checked by watching network activity while formatting: after the page had loaded, formatting a document made no network requests at all. The page does load its styling and scripts from a public CDN (jsDelivr) when it opens, but those requests do not contain what you paste.

Two caveats are worth knowing. First, the history described earlier is stored in your browser on your device, so clear it on shared machines. Second, as a general habit, remove API keys, tokens and personal data from anything you paste into any website. If the data is sensitive, an offline option works just as well: python3 -m json.tool --indent 2 file.json or jq . file.json format a file locally, and most code editors have a built-in "format document" command.

Using formatting in debugging and code review

Formatted JSON pays off most when you are comparing or discussing data. One value per line means a diff shows exactly which field changed, instead of one enormous changed line. A few habits that help:

• Format API responses before pasting them into a bug report so reviewers can scan them.
• Commit JSON fixtures and config files with one consistent indent size, so later edits do not create noisy whitespace-only diffs.
• When a request fails with a parse error, paste the payload into the formatter first: the position in the message tells you where the break is.
• Validate before you format when you only need to know if a document is well formed, and minify before you send when size matters.

Quick answers

Does formatting change my data? Not the structure or values you would normally care about, but see the cases above: very large integers, number formatting, duplicate keys, key order for number-like keys, and escapes can differ from your original text.

Why does my JSON with comments fail? Standard JSON has no comment syntax. Remove the comments or use a tool that targets JSONC or JSON5.

Is there a size limit? The tool's code sets none; very large documents are limited by your browser's memory and responsiveness. For multi-megabyte files, a desktop editor or jq is more comfortable.

Can it sort keys or fix errors automatically? No. It formats valid JSON and reports why invalid JSON fails; it does not guess how to repair it, which is deliberate, since a wrong guess would change your data.