Format JSON Online: Pretty-Print, Minify and Validate

To format JSON online, paste it into the box, choose an indent size, and read the pretty-printed result. The same input also produces a minified version, so you can switch between readable and compact without a second tool. Invalid JSON returns an error instead of a broken layout, and the parsing happens in your browser.

That combination — validate, pretty-print, minify — covers most day-to-day JSON work. You paste a response from an API, a config file, or a log line, and you immediately see whether it is valid and what shape it has. It is a quick check.

#What the formatter does

The tool parses the input as strict JSON. If parsing succeeds, it returns two outputs:

• Formatted: the same data with one value per line, indented by 2, 4 or 8 spaces.
• Minified: the same data with all insignificant whitespace removed.

Both preserve the order of object keys as they appeared in the source. Strings are re-escaped consistently, and Unicode characters are kept readable rather than converted to escape sequences. Nothing is stored, because the work happens locally.

If parsing fails, the tool reports an error instead of guessing. That is the useful behaviour: a formatter that silently fixes your JSON can hide a real problem in an API payload.

#How to format JSON

1. Open the JSON formatter.
2. Paste or type your JSON into the input box.
3. Choose an indent size: 2 spaces (default), 4 spaces, or 8 spaces.
4. Press Format.
5. Copy the pretty-printed output, or switch to the minified version if you need the compact form.

The indent setting only affects presentation. It does not change the data, and it does not affect the minified output.

#Pretty-print vs minify

For an API request or a config file, minified saves bytes. For a code review or a bug report, pretty-printed is the right form. Because both come from the same parse, you can trust that they represent the same data.

#The errors you will actually see

Strict JSON has a small set of rules, and most invalid input breaks one of them:

• Trailing commas. {"a": 1,} is not valid JSON. JavaScript object literals allow it; JSON does not.
• Single quotes. JSON strings use double quotes. 'name' is invalid.
• Unquoted keys. {name: "Ada"} is invalid. Keys must be strings.
• Comments. // and /* */ are not part of JSON. A config file that allows them is not strict JSON.
• Missing commas or brackets. A truncated API response is a common cause.
• NaN and Infinity. These are JavaScript values, not JSON numbers.
• A byte-order mark or stray text before the opening brace.

The error message points at the problem rather than dumping a stack trace. Fix the input and format again; there is no partial output to reason about.

#Common problems and fixes

The JSON is valid in JavaScript but rejected here. JavaScript object literals are more permissive than JSON. Convert single quotes to double quotes, quote every key, remove comments and trailing commas.

A large integer changed value. JavaScript numbers are IEEE 754 doubles, so integers beyond 2^53 lose precision. An ID like 9007199254740993 may come back different. If exact big integers matter, keep them as strings in the JSON.

Duplicate keys disappeared. Strict parsers keep the last value for a repeated key. The formatter does not warn about duplicates, so check the source if a value looks unexpectedly overwritten.

The output reordered my keys. It should not: insertion order is preserved for non-numeric keys. Numeric-looking keys can be ordered numerically by the JavaScript engine, which is a language behaviour rather than a formatter choice.

Escapes look different. The formatter normalises escaping. \/ becomes /, and Unicode may appear as the character rather than \uXXXX. The decoded value is the same.

The page struggles with a huge file. Very large JSON can be slow in any browser tab. Split the payload or use a command-line tool such as jq for multi-megabyte documents.

I need to compare two versions. Format both with the same indent, then use a text diff. Consistent formatting makes the real changes visible.

#Tips for working with JSON

• Validate before you debug. A syntax error and a logic error look similar in a log. Formatting first rules out the syntax case.
• Use 2 spaces for sharing. It is the most common convention and keeps deeply nested payloads readable without pushing lines off-screen.
• Minify only at the boundary. Keep the readable version in your repo and minify for transport or storage.
• Do not use a formatter as a fixer. If a payload is invalid, find out why. Silent repair hides broken producers.
• Convert to a table when the shape is tabular. The JSON to CSV converter turns an array of objects into rows you can open in a spreadsheet.
• Generate types from the shape. If you are about to hand-write a model, the JSON to Go struct generator can produce one from a sample.
• Decode tokens separately. A JWT is not JSON until its payload is decoded; the JWT decoder handles that step.

#A note on JSON5 and JSONC

Some tools accept JSON5 or JSON with comments. This formatter does not. If your input uses comments, trailing commas, single quotes or unquoted keys, it will be rejected until you convert it to strict JSON. That is intentional: accepting a superset makes it unclear whether the output will work in the system that consumes it.

For configuration files that legitimately allow comments, keep them in their native format and validate with the tool that owns the format. Do not round-trip them through a strict JSON formatter.

#Frequently asked questions

#Bottom line

Format JSON to read it, minify it to ship it, and treat a parse error as useful information rather than an obstacle. The tool does all three from the same input, locally. Start with the JSON formatter, and move to the JSON to CSV converter when you need the data in rows rather than braces.