Is my JSON sent to a server?

No. The formatter runs entirely in your browser, so the data you paste never leaves your device. You can safely format payloads that contain production data.

Why does my JSON fail to parse?

The most common causes are trailing commas, single quotes instead of double quotes, and unquoted keys. The error message shows the position where parsing stopped, which is usually one or two characters after the real mistake.

What indentation should I use?

Two spaces is the most common convention for JSON in web projects and keeps diffs narrow. Four spaces is easier to scan in deeply nested documents, and tabs respect whatever width each developer has configured.

How large a file can I format?

Anything up to a few megabytes is comfortable. Beyond that the limit is your browser's memory rather than the tool itself.

JSON Formatter, Validator and Minifier

What this tool does

This JSON formatter takes any JSON document and rewrites it with consistent indentation, so a minified API response becomes something you can actually read. It also works in reverse: minify strips every space and newline to produce the smallest valid payload.

Validation happens on every keystroke. When the document cannot be parsed, you get the parser's own error message rather than a generic failure, which is usually enough to locate the problem. Nothing is uploaded — the formatter runs in your browser, so you can paste a production payload without it leaving your machine.

How to use it

Paste your JSON into the input box, or type it directly.
Choose the indentation you want — two spaces, four spaces, or tabs.
Press Format to beautify, or Minify to collapse the document to a single line.
Copy the result, or download it as a .json file.

Sorting keys alphabetically is optional and off by default. It is useful when you want to compare two documents that carry the same data in a different order: sort both, and the diff shrinks to the values that actually changed instead of showing every line as moved.

The four errors that account for most failures

When a document refuses to parse, the cause is almost always one of these:

A trailing comma after the last item of an object or array. Valid in JavaScript, invalid in JSON, and the single most common mistake when a payload is written by hand.
Single quotes. JSON requires double quotes for both keys and string values. A JavaScript object literal pasted straight from a console will fail here.
Unquoted keys. {name: "Revin"} is a JavaScript object; {"name": "Revin"} is JSON.
A stray value type. NaN, Infinity and undefined exist in JavaScript but have no JSON representation. A serialiser that emits them produces a document nothing can read back.

The position reported in the error is where parsing stopped, which is typically one or two characters after the real mistake. Look just before it.

Indentation: which one to pick

Two spaces is the most common convention for JSON in web projects and keeps diffs narrow, which matters when the file is committed to a repository. Four spaces is easier to scan in deeply nested documents. Tabs respect whatever width each developer has configured, at the cost of rendering differently across tools.

If the file lives in version control, match whatever is already there. A reformat that changes every line buries the one change that mattered in a diff nobody wants to review.

When formatting is not enough

A formatter fixes readability, not correctness. If your JSON parses but the receiving system rejects it, the problem is the shape of the data rather than its layout: a number sent as a string, a missing required field, a date in a format the API does not accept, or a null where the schema demands a value. Compare your payload against the API's schema before assuming the formatter changed something — it never alters values, only whitespace and key order.

JSON Formatter