JSON Formatter

Format, validate and inspect JSON in your browser

Paste JSON into the left panel and the tool parses it immediately — there is no submit step and nothing is uploaded. If the text parses, the right panel shows it re-indented, a statistics strip appears above with object, array and key counts plus maximum nesting depth and byte size, and the Tree View tab becomes usable. If the text does not parse, the output panel stays empty and the input panel shows the parser's exact error message with the line and column it failed at. That split is the whole point: formatting is a side effect of a successful parse, so a document that refuses to format is a document that is not valid JSON, and the error text tells you where.

Everything runs client-side, so payloads carrying production credentials, customer records or internal hostnames never leave the machine. The optional Auto-Redact toggle goes further and masks values that look like secrets before they are rendered.

What the controls actually do

• Indent — 2 spaces, 4 spaces, or a tab character. This is the second argument style passed to the serializer, so it affects whitespace only; the parsed value is identical either way.
• Minify — re-serializes with no whitespace at all. Selecting it disables the indent dropdown, because the two settings are mutually exclusive.
• Sort Keys — recursively rebuilds every object with its keys in sorted order. Array element order is never touched, because array order is semantically meaningful and object key order is not.
• Auto-Redact — replaces values that match known secret shapes or that sit under suspicious key names, and shows a badge with the number of values it masked.
• Line Numbers — gutter on the formatted output, useful when someone is reading you an error position over a call.
• Code View / Tree View — the same parsed value shown as text or as a collapsible node tree with each value's type.

Input can arrive by typing, pasting, the clipboard button, uploading a .json file, or dragging a file onto the input panel; Load Sample drops in a small valid document. Output can be copied or downloaded. Small inputs and every option toggle are encoded into the page URL, so the share button produces a link that reopens the same document with the same settings.

Formatting is not validating

These two words get used interchangeably and they are not the same operation. Beautifying answers “what does this document look like with sane whitespace,” and it is a purely cosmetic transform of something that already parsed. Validating answers one of two much harder questions: is this syntactically well-formed JSON, and separately, does it conform to a schema that says which keys are required and what types they hold.

This tool does the first two. It parses, which is syntactic validation, then re-serializes, which is beautification. It does not check the document against a JSON Schema — a payload where "age" is the string "forty" is perfectly valid JSON and formats without complaint. If an API rejects a body that formats cleanly here, the problem is contract-level, not syntax-level.

One consequence: the output is produced by re-serializing the parsed value, not by reflowing your text, so anything the parser normalises away is gone. Comments, trailing commas and the exact spelling of numbers do not survive — a feature when you want a canonical document, a trap when you expected a whitespace-only diff.

Reading a parse error

Browser engines produce two shapes of message. The better shape names the construct the parser expected and gives an offset plus line and column, for example Expected double-quoted property name in JSON at position 22 (line 4 column 1). The weaker shape appears on a bare token: Unexpected token 'N', "{"score": NaN}" is not valid JSON — no position, just the offending character and a snippet. With the second shape, search for that character rather than counting lines.

The reported position is where the parser gave up, which is frequently one token after the mistake. A trailing comma is the classic case: the comma itself is legal at that point, so the parser only fails when it reaches the closing brace and finds no property name waiting. The error points at the brace on the following line; the fix is on the line before it.

Malformed snippets and the exact error each produces

Two failures the parser will not warn you about

Duplicate keys are the first. {"a":1,"a":2} is accepted and returns {"a":2} — last value wins, silently. RFC 8259 says names within an object should be unique but does not forbid repeats, and languages resolve them differently: some keep the last, some the first, some raise. If a config behaves as though a setting is ignored, look for the same key twice before anything else. Silent number coercion is the second, covered below.

What RFC 8259 actually requires

The grammar is small enough to hold in your head. A JSON text is any single value. Objects are unordered sets of name/value pairs whose names are double-quoted strings; arrays are ordered sequences; the value types are object, array, string, number, true/false and null. Whitespace between tokens is limited to space, tab, line feed and carriage return. Points people get wrong:

• A top-level scalar is legal. 42, "hi" and null are each a complete JSON text. The old restriction to objects and arrays came from RFC 4627 and was lifted.
• Numbers have no defined range or precision. The grammar describes the syntax of a number and says nothing about what a parser must be able to represent, which is exactly where interoperability breaks.
• The forward slash needs no escape. "a/b" is fine, and "a\/b" means the same thing — a legacy habit from embedding JSON in HTML script tags.
• Exchanged JSON must be encoded as UTF-8. A BOM is not part of the text and parsers are not required to tolerate one.
• Control characters below U+0020 must be escaped inside strings, including tab and newline.
• Object key order carries no meaning — a consumer relying on it is relying on an implementation detail.

Number precision and why large integers change

JavaScript parses every JSON number into an IEEE 754 double. Integers are exact only up to 9007199254740991, the value exposed as Number.MAX_SAFE_INTEGER. Feed the formatter {"id": 9007199254740993} and the output reads {"id":9007199254740992} — the document changed value, quietly, with no error anywhere. Snowflake IDs, Twitter-style identifiers, 64-bit database primary keys and nanosecond timestamps all live above that ceiling.

The same round trip normalises other spellings: 1.0 becomes 1, 1e2 becomes 100, -0 becomes 0. A value larger than a double can hold, such as 1e400, parses to infinity and serializes as null. Representation error is preserved rather than introduced: 0.30000000000000004 stays exactly that, being the shortest decimal that round-trips to the same double.

The rule is that any identifier you never do arithmetic on should travel as a string. If you cannot change the producer, do not run a large-integer payload through a JavaScript formatter before diffing it — the diff will show changes the network never made. That applies to every browser-based JSON tool, not just this one.

Key ordering and what Sort Keys really produces

Sorting keys is the fastest way to make two structurally identical documents diff cleanly, so it is worth reaching for before a code review or a config comparison. The sort is lexicographic on the string form, not numeric or locale-aware: keys "1", "2" and "10" sort as 1, 10, 2, and uppercase sorts before lowercase by code point, so "Zebra" precedes "apple".

Separately, JavaScript places integer-like keys first in ascending numeric order regardless of insertion or sort order. Format {"b":1,"2":2,"a":3,"10":4} without sorting and the output begins {"2":2,"10":4, then "b", then "a". That is the language's property enumeration rule, not a choice the tool made, and it is one more reason a map keyed by ID is usually better modelled as an array of objects.

JSON, JSON5, JSONC and NDJSON

A file named .json that a strict parser rejects on a comment is almost always JSONC. Strip the comments rather than hoping every consumer is lenient: tolerance is a property of one parser, not of the format. NDJSON gives itself away as Unexpected non-whitespace character after JSON at the start of line two. To inspect one record, copy that line; to convert a whole file, wrap the lines in brackets and join them with commas, which yields ordinary JSON.

Minifying, and when it is worth doing

Minifying strips every byte of insignificant whitespace. It changes nothing semantic, so it is safe on the way out and reversible on the way in. It earns its keep wherever the document is transmitted or stored at volume — request bodies, queue messages, cache values, database columns — and in any field with a hard size cap such as a cookie, a URL parameter, or a log line a collector will truncate.

Where it does not help is anywhere the transport already compresses. Indentation is highly repetitive, so gzip or brotli removes nearly all of its cost and minifying an already-compressed response is close to a rounding error. Against that, a minified document is unreadable in logs and produces useless diffs. Keep the indented form in version control and minify at the edge.

Working with large files

Everything happens in one browser tab, so the ceiling is that tab's memory and DOM responsiveness, not a server limit. Parsing is fast; rendering is what gets slow, because a formatted megabyte becomes an enormous number of DOM nodes. Practical tactics:

• Turn on Minify if you only need to confirm a large document parses — you get the statistics strip and a valid/invalid answer without rendering thousands of indented lines.
• Switch to Code View rather than Tree View, which walks every node and materialises an object for each one.
• Turn off Line Numbers, which adds a gutter element per line.
• Use Upload or drag and drop instead of pasting — very large clipboard pastes are the slowest path in.
• For files that genuinely will not fit — multi-gigabyte exports, NDJSON logs — use a streaming command line tool such as jq, which does not need the whole document resident.
• Share links carry the document only when it is small; above roughly a page of text the link preserves your settings but not the payload.

The statistics strip is useful for sizing work before you do it: max depth tells you how nested a response is before you write the access path, and key and array counts tell you whether a slow-feeling payload is genuinely large or merely deeply nested.

Redacting before you share

Turn on Auto-Redact and the tool masks values matching recognisable secret shapes — AWS access keys, bearer tokens, JWTs, GitHub, Slack, Stripe and OpenAI-style keys, PEM private key headers, long hex strings and UUIDs — plus personal fields such as emails, phone numbers, card-shaped digit strings and SSNs. It also masks values under key names implying a secret: password, secret, token, api key, credential, authorization, client secret, cvv, pin. A badge shows how many were masked, and a zero on a payload you expected to contain a key means the pattern did not match, so check by eye.

Treat it as a safety net, not a guarantee: a high-entropy value under an innocuous key name may not match, and business data such as account numbers or internal hostnames is not what the patterns look for. Read the redacted output before pasting it anywhere. Redaction runs before formatting, so what you copy, download or share is the masked document.

A workflow that catches most problems

Paste the raw response exactly as received — the mess is the evidence. If it fails, read the error shape: a named-construct message with a position points at a syntax slip near that offset, while a bare-token message points at a foreign literal such as NaN, None, True or undefined, which usually means the producer serialized with the wrong library. Unexpected end of JSON input means an empty body, so check the status code, and a truncation error mid-array means a timeout or size limit upstream, not a formatting bug.

Once it parses, use Tree View to confirm types rather than trusting the visual shape — "1" and 1 look nearly identical in indented text and behave very differently downstream. Then sort keys and minify for a canonical form and diff that, so two environments' responses compare without whitespace or ordering noise. The chain buttons under the output pass the formatted document straight into the diff checker, the format converter, base64 and URL encoders, or a hash generator.