Is the data I paste sent to a server?

No. Parsing and serialization both run through the browser's own JSON.parse and JSON.stringify, and no network request carries your input anywhere. That said, some organizations forbid pasting internal data into third-party sites at all, so check your own policy before using production data.

Why does JSON with comments fail?

Standard JSON has no comment syntax. Files like VS Code's settings.json or tsconfig.json are actually JSONC, an extended format that those editors accept. Strip the comment lines before validating here.

Can it handle large files?

Everything runs in browser memory, so a few megabytes is usually fine, but tens of megabytes may freeze the tab. For large files a command-line tool is safer — for example, jq . data.json.

Will my key order change?

No. JSON.parse preserves object key insertion order and JSON.stringify writes them back in that order. One exception: keys that look like integers ("1", "2") get hoisted into numeric order by JavaScript's own property-ordering rules.

Can numeric precision be lost?

Yes. JavaScript numbers are double-precision floats, so the safe integer range is ±2^53−1. Larger IDs — Twitter snowflake IDs, some database bigints — can come back subtly changed after a parse round trip. The standard fix is to have the API send such values as strings.

Is validation the same as schema validation?

No. This tool does syntax validation: is this parseable JSON? Checking that required fields exist and types match is structural validation, which is JSON Schema's job — the JSON Schema Generator tool can draft one for you.

JSON Formatter - Free Online Tool

JSON Formatter Guide and Parse Error Reference

JSON has very few rules, which makes it easy to learn — and makes parser errors unhelpfully terse when something breaks. This tool indents whatever you paste so you can see the structure, and when the syntax is invalid it shows you the browser parser's message verbatim. Below is how to read those messages, and when to format versus minify.

What standard JSON does and doesn't allow

Most parse failures come from treating JSON as if it were a JavaScript object literal. JSON descends from JavaScript but is a far narrower spec (RFC 8259), and plenty of notation that works fine in JavaScript is an error in JSON.

Notation	Standard JSON	Why
{"a": 1}	Valid	Keys must be double-quoted strings
{a: 1}	Invalid	Unquoted keys are JavaScript syntax, not JSON
{'a': 1}	Invalid	Single quotes cannot delimit JSON strings
{"a": 1,}	Invalid	Trailing commas are not permitted
// comment	Invalid	JSON has no comment syntax at all
NaN, Infinity	Invalid	JSON numbers must be finite decimals — use null
{"a": undefined}	Invalid	undefined is not a JSON value — use null
1e-7, -0.5	Valid	Exponents and negatives are ordinary JSON numbers

How to use it

Paste JSON into the left pane. A single-line API response is fine as-is.
Pick an indent width: 2 spaces, 4 spaces, or 1 tab. If your team has no convention, 2 spaces is a safe default.
Press Format to get the indented result on the right. If the syntax is broken you'll get a red error message instead.
Minify does the opposite — it strips all whitespace and newlines down to one line.
Check the stats row for key count, object/array counts, maximum nesting depth, and byte size.
Copy the result to your clipboard, or download it as a .json file.

Reading the error messages

This tool surfaces whatever the browser's JSON.parse threw, unmodified. The position information in the message (position N, or line N column M) is your main clue. Keep in mind that a parser reports where the problem became undeniable, not where it started — an unclosed brace, for example, is always reported at the very end of the document.

Message	Cause	Fix
Unexpected token ' ...	Single-quoted string	Switch to double quotes
Unexpected token } / ]	Trailing comma before the closer	Delete the last comma
Unexpected end of JSON input	Unclosed bracket or quote	Match your opening and closing pairs
Unexpected token N / I	NaN or Infinity in the payload	Replace with null or a string
Bad escaped character	Illegal character after \	Only \" \\ \/ \b \f \n \r \t \uXXXX are legal
Unexpected non-whitespace ...	A second value after the first	A JSON document has exactly one top-level value
Unexpected token o in JSON	Parsing the string "[object Object]"	Find the code that stringified an object by concatenation

Format versus minify

Formatting is for humans. Use it to understand nesting, confirm that a response contains the fields you expected, or paste a payload into a code review. Indentation never changes the data, so it is always reversible.

Minifying is for transport. Removing whitespace typically cuts 10–30% of the bytes, and the deeper the nesting and the shorter the keys, the bigger the saving. But most HTTP responses already travel under gzip or brotli, and those compressors handle repeated whitespace well — so the real wins are on paths with no compression layer: localStorage values, URL query parameters, and fields with hard character limits.

Don't minify config files. Collapsing package.json or tsconfig.json onto one line makes every Git diff a whole-file change, which destroys reviewability.

How to read the structure stats

Maximum depth is the most actionable number here. Once depth passes six or seven, client code fills up with long optional-chaining expressions and becomes brittle against schema changes — treat it as a prompt to revisit the response shape.

Read key count together with byte size to gauge how much of a payload you actually need. If a list endpoint returns hundreds of kilobytes and the UI only reads a handful of fields, that's an argument for a field-selection parameter.

Common uses

Inspecting REST or GraphQL responses to confirm field names and nesting
Making GitHub, Stripe, or Slack webhook payloads readable
Syntax-checking config files like package.json, tsconfig.json, composer.json
Expanding MongoDB or Firestore documents copied out of a console
Pulling one line out of a JSON Lines log file and unfolding it
Decoding state saved in localStorage or cookies to inspect it

Frequently Asked Questions

Is the data I paste sent to a server?: No. Parsing and serialization both run through the browser's own JSON.parse and JSON.stringify, and no network request carries your input anywhere. That said, some organizations forbid pasting internal data into third-party sites at all, so check your own policy before using production data.
Why does JSON with comments fail?: Standard JSON has no comment syntax. Files like VS Code's settings.json or tsconfig.json are actually JSONC, an extended format that those editors accept. Strip the comment lines before validating here.
Can it handle large files?: Everything runs in browser memory, so a few megabytes is usually fine, but tens of megabytes may freeze the tab. For large files a command-line tool is safer — for example, jq . data.json.
Will my key order change?: No. JSON.parse preserves object key insertion order and JSON.stringify writes them back in that order. One exception: keys that look like integers ("1", "2") get hoisted into numeric order by JavaScript's own property-ordering rules.
Can numeric precision be lost?: Yes. JavaScript numbers are double-precision floats, so the safe integer range is ±2^53−1. Larger IDs — Twitter snowflake IDs, some database bigints — can come back subtly changed after a parse round trip. The standard fix is to have the API send such values as strings.
Is validation the same as schema validation?: No. This tool does syntax validation: is this parseable JSON? Checking that required fields exist and types match is structural validation, which is JSON Schema's job — the JSON Schema Generator tool can draft one for you.

💡 Note: If the error position points to the very end of your document, it's almost always an unclosed bracket or quote. Splitting the input in half and validating each part separately narrows it down fast.

{ }JSON Formatter