JSON Formatter & Validator

JSON — JavaScript Object Notation — is the format most software uses to exchange structured data. It is deliberately simple: objects, arrays, strings, numbers, booleans and null, and nothing else. That simplicity is why almost every API, configuration file and log pipeline speaks it.

A JSON formatter takes that data in whatever shape it arrives — minified onto a single line, indented three different ways, or copied out of a terminal — and rewrites it with consistent indentation and one value per line. The result is the same data, laid out so a person can read it.

This works because whitespace between JSON tokens carries no meaning. A parser treats these two documents as identical, so a formatter can move freely between them without ever changing what the data says:

1{"id":1,"tags":["api","json"],"owner":{"name":"Ada","active":true}}

1{2  "id": 1,3  "tags": ["api", "json"],4  "owner": {5    "name": "Ada",6    "active": true7  }8}

Most formatters double as validators, because a document has to be parsed before it can be re-printed. If parsing fails, there is no formatted output to show — only an error, which is exactly the information you needed.

Machines are happy with a single 400 KB line. People are not. Formatting is what turns an opaque blob into something you can reason about, and it pays for itself in a few common situations:

• Reading an API response. Most APIs return minified JSON to save bandwidth. Formatting reveals the shape of the response — which fields are nested, which are arrays, which came back null.
• Finding the break in a payload. When a request is rejected as malformed, a validator points at the exact line and column instead of leaving you to count brackets.
• Producing a readable diff. Two minified documents differ on line one and nowhere else, which tells you nothing. Format both — optionally with keys sorted — and a diff shows precisely which values moved, or hand the two documents to the JSON diff and let it line them up for you.
• Reviewing configuration. Config files get read far more often than they get written. Consistent indentation makes an unfamiliar file approachable.
• Shrinking a payload before shipping. The reverse operation matters too: minifying strips every optional byte before data goes over the wire or into storage, and reports how many bytes that saved.

Everything below runs in your browser. There is no upload step, no queue and no account.

Beautify and minify

Beautify re-prints the document with your chosen indentation — two spaces, four spaces or tabs — putting each property and array item on its own line. Minify does the opposite, removing every optional space and newline to produce the smallest valid representation. Both run against the parsed data, not the raw text, so the output is guaranteed to be well-formed.

Live validation with exact positions

The document is validated as you type. Invalid JSON is underlined in the editor, and the status bar names the problem in plain language along with its line and column — plus a button that jumps the cursor straight to it.

Interactive tree view

The tree tab turns the document into a collapsible outline — the same view the dedicated JSON viewer is built around. Expand and collapse individual branches, jump to a level, or expand everything at once. Searching filters the tree to matching keys, matching values, or both, keeping the ancestors of each match so results stay in context. Every row can copy its key, its value or its JSON path.

Statistics

Character and line counts, how many objects, arrays and keys the document contains, how deeply it nests, and the byte size of the input, the formatted output and the minified output — so the saving from minifying is a number rather than a guess.

Sorting, escaping and clean-up

Optional transforms that change the document rather than just its layout: sort every object’s keys alphabetically for stable diffs, escape non-ASCII characters as \uXXXX for systems that expect pure ASCII, and drop properties that are null or empty. Each one is off by default and clearly labelled, because they alter your data.

A real editor

Line numbers, syntax highlighting, code folding, bracket matching, undo and redo, and find-and-replace. Only the visible lines are rendered, so a multi-megabyte document scrolls as smoothly as a short one.

Files, clipboard and print

Upload a .jsonfile or drop one anywhere on the editor. Copy the output, download it formatted or minified, or print it. Files are read with the browser’s own FileReader — they are never transmitted.

Duplicate key detection

Duplicate keys are legal to write but silently lossy: every parser keeps the last one. Rather than let that pass unnoticed, each duplicate is reported with its path and line so you can decide what was meant.

1. 1. Add your JSON. Paste it into the input panel, drag a .json file onto the page, or use the upload button. The example document is loaded to begin with — replace it or clear the editor.
2. 2. Check the status bar. It reads Valid JSON as soon as the document parses. If it reads Invalid JSON, the message underneath names the problem and its position; use the line and column button to jump there.
3. 3. Choose your output. Beautify re-prints the document with indentation; Minify collapses it to a single line. Open the options panel to pick two spaces, four spaces or tabs.
4. 4. Apply any transforms. Sort keys, escape unicode, or remove null and empty properties if you want them — all optional, all off by default.
5. 5. Take the result. Copy it, download it as data.json or data.min.json, print it, or press Swap to move the output back into the input and keep working on it.

To reformat an entire file in place, turn on Format on paste — the input is beautified the moment valid JSON lands in it. If you know this job as beautifying rather than formatting, the JSON beautifier is the same tool under that name.

Validation is parsing. The document is read left to right and broken into tokens — braces, brackets, colons, commas, strings, numbers and the three bare words true, false and null. Those tokens are then checked against the JSON grammar: a value, then optionally a comma and another value, until the container closes.

The moment a token appears where the grammar does not allow it, parsing stops. The position of that token is the error position, which is why a good validator can give you a line and a column rather than a vague complaint. Consider:

1{2  "id": 1,3  "tags": ["a", "b"],4}

After the comma on line 3, the grammar requires another property. Instead it finds }, so the document is rejected with “Unexpected comma at line 3” and the explanation that trailing commas are not allowed. The fix is to delete one character.

Two details are worth knowing. First, the reported position is where the parser noticed the problem, which is not always where you made it — an unclosed brace on line 12 is usually reported at the end of the file, because that is the first point at which it becomes impossible to continue. Second, validation only checks syntax. It confirms the document is well-formed JSON; it does not check that it matches a schema, that email holds an email address, or that a required field is present. For that you need JSON Schema, which is a separate layer on top.

• Pick one indentation and keep it. Two spaces is the most common convention and keeps deep documents narrow. What matters is that a repository does not mix styles — that produces diffs full of whitespace noise.
• Minify in transit, format at rest. Send the small version over the network; keep the readable version in source control where humans review it.
• Sort keys when you need stable diffs. If two services serialise the same object with different key orders, sorting makes them comparable.
• Never allow duplicate keys. They parse, but the earlier value is silently discarded. Treat any duplicate as a bug in whatever produced the document.
• Use UTF-8 and leave characters unescaped. JSON is UTF-8 by default and "café" is perfectly valid. Only escape to \uXXXX when a downstream system genuinely requires ASCII.
• Keep numbers in range. JSON numbers are arbitrary precision on paper, but most parsers read them as 64-bit floats. Identifiers beyond 2⁵³ should be strings, or they will quietly lose their last digits.
• Prefer omitting a field to sending null— unless null carries meaning of its own, such as “explicitly cleared”. Being consistent about which you mean saves a lot of defensive code downstream.
• Remember JSON has no comments. If a file needs explanation, add a _comment property or keep the notes alongside it. JSONC and JSON5 allow comments but are not JSON, and standard parsers will reject them.