JSON Formatter

How this formatter works

Paste or type JSON into the editor and press Format — or use Ctrl+Enter. The tool parses your input with the browser's native JSON parser, then re-serialises it with the indentation you chose. If the input is valid you get formatted output plus a breakdown of its size, line count, total keys and nesting depth.

If the input is not valid, the tool does something most formatters do not: it explains the problem. Rather than repeating the parser's message, it scans your text to find exactly where the grammar breaks, reports the line and column, shows the offending line, and names the specific mistake — a trailing comma, a single-quoted string, an unquoted key — along with what to change.

This matters because browser error messages are inconsistent. Some include a position, some do not, and the ones that do not will send you hunting through a large document with no clue where to start. Locating the fault directly is more reliable than reading whatever the engine happened to say.

Everything runs in your browser. There is no upload, no request, and no server-side copy of your data. You can verify that yourself: open your browser's developer tools, switch to the Network tab, and click Format. Nothing is sent.

The seven JSON errors you will actually hit

Nearly every invalid JSON document fails for one of a small number of reasons, and almost all of them come from writing JavaScript out of habit. JSON is a strict subset of JavaScript's object syntax — everything JSON allows is valid JavaScript, but plenty of valid JavaScript is not JSON.

• Trailing commas. A comma after the final item in an object or array is fine in modern JavaScript and invalid in JSON. This is the single most common failure.
• Single quotes. JSON requires double quotes on every string and every key. 'name' must become "name".
• Unquoted keys. JavaScript permits { name: "x" }; JSON requires { "name": "x" }. Every key is a quoted string, without exception.
• Comments. There is no // or /* */ in JSON. Strip them, or switch to a format such as JSON5 whose parser accepts them.
• NaN, Infinity and undefined. These are JavaScript values with no JSON equivalent. Use null, a number, or a string, depending on what the consumer expects.
• Unescaped control characters. A literal newline inside a string must be written as \n. Tabs, quotes and backslashes need escaping too.
• A byte-order mark. Some editors prepend an invisible BOM, which makes a parser fail at position 0 on a file that looks perfect. Save as UTF-8 without BOM.

One more failure deserves its own mention because it produces no error at all: duplicate keys. The specification neither permits nor forbids them, and JavaScript's parser silently keeps the last one. If a value is inexplicably missing from a parsed object, a duplicate key earlier in the document is a likely culprit.

When you will reach for this

• Debugging an API response. Paste the raw body from your network tab and the structure becomes readable immediately.
• Reviewing configuration files. package.json, tsconfig.json, deployment manifests and CI definitions are all JSON, and all easier to review formatted.
• Comparing two payloads. Turn on Sort keys A–Z and format both; matching fields line up, so a diff shows real differences rather than reordering noise.
• Validating before shipping. Catch a syntax error at your desk rather than in a failing deploy.
• Preparing sample data. Format a fixture before committing it so the next reader can follow it.
• Learning the format. Paste something that fails and read the explanation — it is a faster way to internalise the rules than reading a specification.

Formatting, minifying, validating and linting

These four words get used interchangeably and mean different things. Formatting adds whitespace for human readers. Minifying removes it for machines. Validating answers whether the document conforms to the JSON grammar at all. Linting goes further and checks conventions — key naming, ordering, whether values match an expected schema — none of which the JSON specification has an opinion about.

This tool formats, minifies and validates. It does not lint, because linting rules are project-specific and a generic tool would guess wrong. If you need schema validation, JSON Schema is the standard worth learning.

On minifying: it is worth doing, but rarely the win people expect. Whitespace compresses extremely well, so on any connection using gzip or brotli — which is essentially all production traffic — the difference between formatted and minified JSON after compression is small. Enable compression first. Minify second.

Practical tips

• Two-space indentation is the de facto standard for JSON and keeps deeply nested documents from running off the right edge.
• Store dates as ISO 8601 strings. They sort correctly as text, they are unambiguous about time zone, and they survive a round trip through any language.
• Prefer null over an empty string for missing values. Null says 'no value'; an empty string says 'a value that happens to be empty', and the distinction matters to whatever reads it.
• Keep keys consistent. Pick camelCase or snake_case and hold to it across an API — mixed conventions cause real bugs at integration boundaries.
• Be careful with large integers. JSON numbers are IEEE 754 doubles in JavaScript, so anything above 2^53 loses precision. Send large IDs as strings.
• Never build JSON with string concatenation. Use your language's serialiser; hand-assembled JSON breaks the moment a value contains a quote.

In short

A JSON formatter is a small tool that removes a recurring, avoidable friction: reading data written for machines. This one formats, minifies, validates, and — when something is wrong — tells you what and where in plain language rather than leaving you to decode a parser's complaint.

It is free, needs no account, and runs entirely in your browser, so the data you paste stays on your machine. Bookmark it, use it as often as you like, and if there is a tool you keep wishing existed, tell us — the list above is what we are building next.