How to Format and Validate JSON (and Find What's Actually Broken)

JSON is unforgiving. A single missing comma, or an extra one, makes an entire payload fail to parse, and the error most languages give you ("Unexpected token" somewhere on a line that is 40,000 characters long) doesn't make the problem easy to find. A formatter does two jobs at once: it makes JSON readable, and it tells you exactly where it is broken. This guide covers how to do both, the mistakes that cause almost every JSON error, and a method for finding a fault in a large file quickly.

Why minified JSON is so hard to debug

API responses, logs and config exports are usually minified, with every space and line break removed to save bytes. That is efficient for machines but unreadable for people. A 200-line structure collapsed onto one line makes it nearly impossible to see where an object ends, which array you are inside, or whether a bracket is missing. Formatting (also called beautifying or pretty-printing) puts each key on its own line and indents nested levels, so the shape of the data becomes visible.

How to format and validate JSON

1. Open the JSON Formatter and paste your JSON, minified or not.
2. Validation runs as you type. If the JSON is valid, the header shows its size and node count. If it is broken, the parser's error message appears, usually naming the unexpected character and its position.
3. Click Prettify for readable output with two-space indentation, or Minify to strip it back down to one compact line.
4. Copy the result or download it as a .json file.

Everything runs in your browser. That matters more than it sounds: API responses and config files often contain tokens, customer data and internal URLs that you shouldn't paste into a site that sends them to a server.

The mistakes behind almost every JSON error

JSON looks like a JavaScript object, but it is much stricter. Most errors come from writing it the JavaScript way:

• Single quotes: strings and keys must use double quotes.
• Unquoted keys: every key is a string, so every key needs quotes.
• Trailing commas: allowed in modern JavaScript, forbidden in JSON. This is the classic "works in my code, fails when parsed" bug.
• Comments: JSON has no comments. Remove // and /* */ lines, or use a format designed for them (JSONC, JSON5, YAML) if your tool supports it.
• Special values: undefined, NaN and Infinity aren't valid. Use null or a string.
• Unescaped characters in strings: a raw line break, tab or double quote inside a string breaks the structure. They must be written as \n, \t and \". Windows paths are a common trap: "C:\new" must be "C:\\new".

How to find the error in a large file

1. Go to the position in the error. Parsers report where they gave up, not where the mistake is. The real fault is usually just before that point: the missing comma at the end of the previous line, or the unclosed string that swallowed everything after it.
2. Look at what comes right before. An "unexpected string" error typically means a missing comma between two properties. An "unexpected end of input" error means an unclosed bracket or brace, usually at the end of a truncated response.
3. Halve the problem. If you can't see it, cut the JSON in half at a sensible boundary, such as between two array items, and validate each half. Keep halving the broken part. Even a huge file takes only a few rounds.
4. Check where it came from. JSON pasted from a chat app, email or document can pick up "smart" curly quotes (“ ”) instead of straight ones, which are invalid. The same goes for copying from a log line that was cut off.

Prettify or minify?

• Prettify when people will read it: debugging, code review, documentation, or committing config files to version control (diffs are far more readable when each key has its own line).
• Minify when machines will read it: API payloads, environment variables, data embedded inside another string, or anywhere bytes matter. Indentation can triple a file's character count.

Validation vs schema validation

A formatter checks syntax: whether the text is legal JSON. It can't tell you whether the data is right: whether price should be a number rather than a string, or whether a required field is missing. That is the job of a JSON Schema, which describes the expected shape. If an API rejects valid-looking JSON, compare it against the API's documentation or schema; the syntax is fine but the content doesn't match what the API expects.

Working with JSON data

• To turn an array of records into a spreadsheet, use JSON to CSV.
• To compare two versions of a config or response, prettify both and paste them into Text Compare. Formatted JSON diffs line by line cleanly.
• To decode a JWT or a Base64 field you found inside a response, use the Base64 decoder.

Frequently asked questions

How large a JSON file can I format?

There is no set limit; it depends on your browser's memory. Multi-megabyte API dumps format comfortably on a modern machine. For very large files, minified output is much lighter to render than prettified.

Why does valid JavaScript fail as JSON?

Because JSON is a strict subset with no single quotes, unquoted keys, trailing commas, comments or undefined. Copying an object literal out of source code almost always needs those fixes first.

Does formatting change my data?

No. Prettify and minify change only whitespace between tokens. Keys, values and order stay exactly the same.

Where can I learn more about formatter features?

Our walkthrough of the JSON formatter covers its features in more detail.