JSON Formatter & Validator

There is no clever parsing here, and that is the point. Your input goes through the browser's native JSON.parse, and the result is re-serialised with JSON.stringify at two spaces, four spaces, or no whitespace at all. Formatting and minifying are the same operation with a different indent argument.

Using the native engine rather than a hand-written parser is a deliberate choice. It means the verdict you get here is exactly the verdict your JavaScript, your API gateway and your build tooling will reach, because it is literally the same implementation. A permissive third-party parser that accepts trailing commas would be worse than useless — it would tell you a payload is fine when the service consuming it will reject it.

Beautifying and minifying produce identical data. Indentation is for humans; removing it is for the wire. Neither changes a single value, so you can format a payload to read it, then minify it again before sending with no risk of having altered anything.

When parsing fails you get the engine's own message plus the position translated into a line and column, which is the part that actually saves time in a two-thousand-line config file.

Three mistakes account for most failures. A trailing comma after the last element of an array or object — legal in JavaScript, forbidden in JSON. An unquoted key, which JavaScript object literals allow and JSON does not. And single quotes instead of double, which JSON never accepts.

The position the engine reports is where it gave up, not always where you went wrong. A missing closing brace early in a document is often reported near the end, because the parser only discovers the imbalance when it runs out of input. If the reported line looks innocent, check what opened above it.

Minifying is also a quick way to sanity-check a payload before sending it: if it minifies without error, it will parse at the other end, whatever the receiving service then decides to do with the contents.

Think about where the JSON you actually need to format comes from. It is an API response you captured while debugging, a config file, a webhook body, a log line. Which means it routinely contains bearer tokens, API keys, session identifiers, internal hostnames, and personal data belonging to real customers.

Most online formatters are server-side: your payload is posted to their backend, parsed there, and returned formatted. It may be written to an access log, captured by an error tracker, or cached. The operator is probably not malicious — but you have still copied production secrets and customer data onto infrastructure you have never assessed, which in most organisations is a reportable event whether or not anything bad follows.

This is also the single most common way engineers leak credentials without ever thinking of it as a leak. Pasting a token into a chat window at least feels like sharing. Pasting a JSON blob into a formatting tool feels like using a text editor, and the payload happens to have an Authorization header in it.

Here the parse happens in your tab. Nothing is transmitted, and it takes ten seconds to confirm: open the Network tab and format something, or disconnect from Wi-Fi and format anyway. Apply that check to any tool you paste a payload into, including this one.

JSON is much smaller than JavaScript. Comments are not permitted in any form. Trailing commas are invalid. Keys must be double-quoted strings. NaN and Infinity are not values, and neither is undefined. Dates have no representation at all — what looks like a date is only ever a string that both ends have agreed to interpret.

There is one behaviour worth knowing about because it is silent rather than an error. JSON numbers are parsed into IEEE-754 doubles, which represent integers exactly only up to 2^53 − 1. Parse 9007199254740993 and you get back 9007199254740992: no error, no warning, just a value that is quietly wrong by one.

This bites in practice, because plenty of systems issue 64-bit integer identifiers — Twitter/X post ids and Discord snowflakes are the classic examples. If an id round-trips through JSON as a number it can come out changed. The fix is on the producing side: send large identifiers as strings. If you are debugging an id that mysteriously differs by one or two, this is almost certainly why.