Does formatting change my data?

No. Pretty-printing only inserts whitespace — spaces, tabs and line breaks — between tokens. Every key, value, bracket and comma stays identical, so a formatted document parses to exactly the same object as the compact original.

Why is the formatted version so much bigger, and does that matter?

Indentation is pure whitespace, which is why the character count can grow by half. In transit it barely counts: gzip and brotli compression remove almost all of that whitespace for free, so a pretty-printed payload and a compact one arrive at nearly the same size. What matters is the file you paste into a script or a config, where you read every line.

My formatted JSON shows an error instead of output. Why?

The document did not parse — usually a missing comma, an unclosed bracket or single quotes where double quotes are required. The message gives the line and character position; fix that spot and format again. The [JSON Validator](/developer-tools/json-validator) reports the same positions with a cleaner explanation.

How do I make the JSON compact again?

Use the JSON Minifier — it strips indentation, line breaks, comments and trailing commas, returning the smallest valid form. That is the version to paste into an API request body or a single-line config value.

Is my JSON uploaded when I format it?

No. Formatting runs entirely in your browser tab. Nothing is sent to a server, so it is safe to use on responses containing API keys, private records or internal identifiers.

Format JSON Data for Readability

JSON is the standard format for data exchange on the web. But raw JSON from APIs often arrives as a single compressed line that is impossible to read. Formatting (pretty-printing) adds proper indentation and line breaks so you can actually understand the structure.

Who Needs This

Developers debugging API responses. Anyone copying JSON from a log file or terminal. Non-technical users trying to read data from a web service. Students learning JSON structure.

What I Tested

I pasted a compact JSON object (2,847 characters, 4 levels of nesting) into the JSON Formatter.

Before formatting: {"users":[{"id":1,"name":"Alice","address":{"city":"London","zip":"EC1A"}},...]} — one line, impossible to scan.

After formatting: Each key-value pair on its own line, nested objects indented by 2 spaces. The output was 4,213 characters (48% larger due to whitespace) but immediately readable. I could see the array structure, identify nested objects, and spot a missing comma that was causing a parse error.

Syntax Highlighting

The formatter color-codes strings (green), numbers (orange), booleans (blue), and null values (red). This makes it easy to spot type errors — like a number stored as a string or a missing quote.

Step-by-Step

(1) Open the JSON Formatter. (2) Paste your raw JSON into the input area (or click 'Load Sample' to see an example). (3) Click 'Format'. (4) The formatted JSON appears instantly with syntax highlighting. (5) Click 'Copy' to copy the formatted output.

Limitation

The formatter cannot fix invalid JSON. If your JSON has a syntax error (missing comma, unclosed bracket, trailing comma), it will show an error message indicating the line and position of the problem. You need to fix the error before formatting.

Common Mistake

Pasting JSON that contains single quotes instead of double quotes. JSON requires double quotes for all keys and string values. If your data uses single quotes, replace them with double quotes before formatting.

How It Compares

VS Code and other code editors format JSON built-in, but they require installation and are not accessible from a browser. JSONLint validates and formats but has a dated interface and no syntax highlighting. Our tool adds color-coded syntax highlighting, error detection, and works entirely in your browser with no upload.

Privacy: All formatting happens in your browser. Your JSON data is never sent to any server. This is important if your JSON contains API keys, user data, or other sensitive information.

Next Step: If you need to validate JSON structure before formatting, use the JSON Validator. It checks for syntax errors and reports the exact position of any problems.

How Much Bigger Does Formatting Make It?

In the test above a 2,847-character object grew to 4,213 characters — about 48 percent larger — purely from indentation and line breaks. The growth depends on nesting depth: four levels with two-space indentation adds two characters per line, plus a newline for every key and value. Deeply nested structures grow the most.

None of that affects correctness, and it is compressed away on any modern HTTP connection. The trade-off is only in human workflows — a formatted file is easier to review in a diff, a compact one is easier to paste into a header or a command line. Keep both: format while you read, minify before you send.

Reading a Deeply Nested Structure

Indentation is what makes nesting visible. When you open a formatted document, count the levels down the left edge: each level of indentation is one bracket deeper, so an array of objects will show its opening bracket on one line and the same indent repeated for every element inside it. Collapsed or misaligned indentation is the fastest sign that a bracket is in the wrong place.

Colours help for the same reason: a green string where a number should be orange means a value arrived quoted from the API, and a blue true or false where you expected text means the opposite. Both are type problems that syntax cannot catch — they are visible only when the structure is spread out.

Formatting for Code Review

Formatted JSON is easier to review for the same reason formatted code is: the structure of the data becomes visible, and structural mistakes stand out against it. A pull request that changes a configuration file should never show up as one long minified line — the reviewer cannot see what moved, and diff tools give up on anything wider than the screen.

Format before committing configuration and fixture files, keep the formatted version in the repository, and let any build step that wants minified input minify it on the way out. Most tools that consume JSON do not care about whitespace anyway, and the ones that do can re-minify deterministically; the repository keeps the readable form where humans will actually look at it.