Data & Format / JSON Tools

JSON Formatter

JSON Formatter reparses your text with a strict JSON parser and prints it back with two-space indentation, so the result is what a conforming parser actually understood rather than a brace-matching guess. Invalid input reports the line and column where parsing stopped. Nothing is uploaded.

How to use

1
Paste the JSON you want to clean up
Drop a compressed API response, a single-line config file or a hand-edited fragment into the input box. Pasting works exactly like typing, and the box reparses as you type, so there is no button to press before you can see whether the document is valid. Nothing is sent anywhere at any point — the parse runs in this tab, using the JavaScript engine your browser already has loaded.
2
Watch the status line while you edit
Under the two panels a status line reports the line count, the byte length and whether the text currently parses. When the document is valid it says so in green; when it is not, the parser complaint appears above with the position at which it gave up. That feedback loop is the reason to paste the whole document rather than checking fragments by hand — most JSON mistakes only become visible once the whole structure is balanced.
3
Format for reading, minify for travelling
Format reprints the document with two-space indentation and one value per line, which is the layout review tools and diff viewers expect. Minify removes every optional space and newline to produce the shortest text that still parses to the same value — the form you want when the JSON has to survive inside a URL query string, an HTTP header, or an environment variable with a length limit.
4
Read the error location, then look one token back
When parsing fails, the tool shows the parser message together with the line and column where it stopped. Treat that column as a hint rather than a verdict: it marks the first character the parser could not accept, which is usually one or two characters after the real mistake. A missing comma at the end of the previous line, or a brace that was never closed further up, both surface as an error somewhere later in the document.
5
Check the byte length before you ship it
The byte count is measured in UTF-8, so every non-ASCII character costs two bytes or more instead of one. A document that looks comfortable on screen can therefore cross a 4 KB header limit or an API request cap without the line count changing at all, and the failure shows up as a truncated request rather than a JSON error. Compare the byte figure against the limit you are targeting, not the character count your editor reports.
6
Copy the result
Copy puts the formatted or minified text on your clipboard and nothing else happens — no request, no upload, no second copy of the payload anywhere. That matters when the document carries API keys, session tokens or customer records, because a formatter that round-trips your text through a backend has written it into that server logs at minimum, and possibly into a database or a cache as well.

Key facts

SpecificationJSON is defined by RFC 8259 and by ECMA-404, which describe the same grammar. RFC 8259 was published in December 2017, obsoleted RFC 7159, and carries the Internet Standard designation STD 90.Source:RFC 8259 / ECMA-404
Number precisionJSON has a single number type, represented as an IEEE 754 double. Integers beyond 2^53 − 1 (9007199254740991) cannot be stored exactly, so a round trip through any parser can change their last digits.Source:RFC 8259 §6
EncodingJSON text exchanged between systems must be encoded in UTF-8, and implementations must not add a byte order mark. A BOM therefore makes a document invalid rather than merely unusual, and a strict parser rejects those three leading bytes.Source:RFC 8259 §8.1
IndentationWhitespace between tokens is insignificant and the specification names no indent width at all. Two-space indentation is a community convention rather than a requirement, which is why any two formatters you compare will disagree slightly about the result.Source:RFC 8259 §2
Duplicate namesNames within an object SHOULD be unique. When they are not, RFC 8259 states that the behaviour of receiving software is unpredictable — many implementations keep only the last pair, some raise an error, and some keep all of them.Source:RFC 8259 §4
Canonical formWhen JSON has to be hashed or signed, formatting stops being cosmetic. RFC 8785 defines the JSON Canonicalization Scheme: no insignificant whitespace, member names sorted, and numbers serialised by ECMAScript rules, so that two equivalent documents produce byte-identical output.Source:RFC 8785 (JCS)

Frequently asked questions

Does this tool store or upload my JSON?

No. Parsing, formatting and minifying all run inside this page using the JavaScript engine your browser already has loaded, and no request leaves your machine at any step. That claim is worth more than it first sounds. JSON payloads routinely carry API keys, session tokens, signed URLs and personal data, so any formatter that round-trips your text through a backend has written it into that server logs at minimum. You do not have to take the statement on trust: open the browser developer tools, switch to the network panel, paste a document and format it. No request appears. The one browser interface the page touches is the clipboard, and only when you press Copy.

Why did the order of my keys change after formatting?

Because formatting reparses your text into a JavaScript object and prints it back out, and JavaScript has its own rules for property order. Keys that look like array indices — "0", "1", "42" — are always enumerated first, in ascending numeric order, ahead of every other key, even if they appeared last in your original document. String keys that are not integer-like keep their original insertion order. So {"b": 1, "2": 2, "a": 3} comes back as {"2": 2, "b": 1, "a": 3}. This is not a defect in this formatter and not something a different tool would do better: any formatter that round-trips through a JavaScript object reorders them the same way. If member order carries meaning in your application, do not round-trip the document through a parser at all — edit the text directly, or sort the members deliberately before you save the file.

The formatter changed one of my numbers. What happened?

Every JSON number is interpreted as an IEEE 754 double-precision floating point value, because that is the only numeric type the JSON grammar has — there is no separate integer type. Any integer whose magnitude exceeds 2^53 − 1, which is 9007199254740991, cannot be stored exactly and is rounded to the nearest representable value. The problem bites hardest with identifiers that happen to be long integers: database bigints, 64-bit hashes, and the snowflake-style IDs issued by platforms such as Twitter, Discord and Mastodon all routinely exceed that limit. The digits change, and if that value was a primary key you are now looking at the wrong record. If such values must survive a round trip unchanged, keep them as JSON strings — which is exactly why so many public APIs return identifiers as quoted strings rather than as numbers.

Can I use comments or a trailing comma?

Not in strict JSON. RFC 8259, the current JSON specification, defines no comment syntax at all and does not permit a comma after the last member of an object or the last element of an array. In practice many configuration formats accept a relaxed dialect — JSON5, the JSONC variant used by VS Code settings files, and the assorted "JSON with comments" modes in linters and bundlers — but those are extensions layered on top, not JSON. Feeding them to a conforming parser such as the one behind this tool produces an error reported at the comment or at the trailing comma. That is the expected result from any strict parser, and a tool that silently accepted them would be producing output that other consumers reject.

My file starts with a BOM and the parser rejects it. Why?

RFC 8259 states that JSON text exchanged between systems must be encoded in UTF-8, and that implementations must not add a byte order mark. A BOM is therefore not part of a valid JSON text, and a strict parser treats the three leading bytes as an illegal character before the document even begins. This usually originates from an editor on Windows saving a file as "UTF-8 with BOM", which looks identical in most text editors and differs only in those first three bytes. Re-save the file as plain UTF-8 without a BOM, or strip the leading EF BB BF sequence, and the document parses. The same three bytes are also a common reason a JSON file fails to load in a shell pipeline that passes the file through unchanged.

Two of my keys had the same name and one silently vanished. Why?

Because in a JavaScript object the last assignment wins. RFC 8259 section 4 says the names within an object SHOULD be unique, and then states plainly that when they are not, the behaviour of software receiving that object is unpredictable: many implementations report the last name/value pair only, some report an error or refuse to parse the object entirely, and some preserve every pair including the duplicates. The parser behind this page belongs to the first group, so {"env": "staging", "env": "production"} formats down to {"env": "production"} and the staging value is gone with no warning at all. Duplicate keys are easy to introduce by accident when a configuration file is merged, when a template is rendered twice, or when an object is assembled by concatenating two strings. If you suspect it has happened, search the raw text for a repeated key name before formatting — once the document has been round-tripped, the evidence is gone.

Related tools

JSON Diff

Compare two JSON documents and see every added, removed and changed value, with the JSON path of each difference and a one-click copy.

JSON Schema Validator

Validate a JSON document against a JSON Schema and get every error with its exact path, including failures nested inside objects and array items. Runs locally.