JSON Formatter — Beautify, Minify & Validate JSON

JSON formatter tips

Use 2-space indent for readability in APIs and configs.
Minify to reduce payload size.
Sort keys when comparing objects in diffs.

A large integer loses its last digits, and the tool still says Valid JSON

This is the most important thing on this page. Formatting parses your JSON into numbers and prints them back, and the number type it parses into is a 64-bit float. Integers above about nine quadrillion cannot be represented exactly, so they come back changed. Measured:

{"id":12345678901234567890} comes back as {"id":12345678901234567000}. The last three digits are gone.
{"id":9007199254740993} comes back as 9007199254740992, one less.
{"v":0.1234567890123456789} comes back as 0.12345678901234568.

In every case the status line said Valid JSON, because it is. The loss is in the round trip, not in your input.

So do not reformat JSON that contains large numeric identifiers and then use the output. Snowflake-style IDs from social platforms, 64-bit database keys and financial values in minor units are all in that range. Use the tool to read and validate, and keep the original for anything you are going to act on.

This is not a defect peculiar to this tool. RFC 8259, the JSON standard, says that “good interoperability can be achieved by implementations that expect no more precision or range than” IEEE 754 double precision provides, and that “implementations will approximate JSON numbers within the expected precision”. Systems that need exact large integers send them as strings for exactly this reason. If you control the producer, quote the id.

Duplicate keys are silently collapsed, and the last one wins

Measured: {"a":1,"a":2} formats to {"a": 2}, reported as valid, with the first value discarded and no warning. The output is shorter than the input and nothing draws your attention to it.

Again this is the standard rather than the tool. RFC 8259 says “The names within an object SHOULD be unique”, that “when the names within an object are not unique, the behavior of software that receives such an object is unpredictable”, and that “many implementations report the last name/value pair only”. This tool is one of the many.

The practical consequence: this tool cannot be used to find duplicate keys, which is a thing people reasonably come here for. If a config is behaving as though a setting were ignored, and you suspect it is declared twice, formatting it here will hide the evidence rather than reveal it.

The validation is strict, and the error message tells you where

Everything that is not JSON is refused with a position rather than a shrug. Measured:

A trailing comma, {"a":1,}: “Expected double-quoted property name in JSON at position 7 (line 1 column 8)”.
Single quotes, {'a':1}: “Expected property name or '}' in JSON at position 1 (line 1 column 2)”.
A /* comment */: “Expected ',' or '}' after property value at position 7”.
NaN: “Unexpected token 'N'”.

All four of those are valid JavaScript and none of them is valid JSON, which is the usual reason a file a developer wrote by hand is rejected here. Trailing commas and comments in particular are allowed in JSON5 and in most editors’ tolerant parsers, and in tsconfig.json and similar files that are JSON with comments by convention. This tool implements the standard, so those files will not validate.

Two smaller normalisations that are easy to miss

Exponent notation is expanded. Measured: 1e3 becomes 1000. The value is identical, the text is not, so a byte-for-byte comparison against the original will differ.
Negative zero becomes zero. Measured: -0 becomes 0. The two are equal in arithmetic and distinguishable in some systems, so if you are round-tripping scientific data, that sign is gone.

Key order is preserved by default, which is worth knowing because JSON objects are unordered by definition and plenty of tools reorder them. Measured: {"z":1,"a":2} keeps z first. Choosing Sort alphabetically gives {"a":2,"z":1}, which is what you want before diffing two files that were written in different orders.

What this tool deliberately does not do

It does not preserve large numbers exactly, as above. For exact integer arithmetic at any size, Number Base Converter uses an exact integer type and does not round.
It does not find duplicate keys, it hides them.
It does not accept comments, trailing commas, single quotes or unquoted keys, so it is not a JSON5 or JSONC parser.
It does not repair broken JSON. It tells you where the first problem is and stops.
It does not validate against a schema, so it cannot tell you a field is missing or the wrong type.
It does not handle JSON Lines, where each line is a separate document. Those must be formatted one line at a time.
No files, no history. Paste in, copy out; nothing is saved.

Nothing is uploaded. The parsing and formatting happen in your browser, and the JSON never leaves your device, which matters because configuration and API responses tend to have credentials in them.

Sources

Number precision and interoperability, and the rule on duplicate names: RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, sections 6 and 4. rfc-editor.org/rfc/rfc8259
The limit above which integers stop being exact: Number.MAX_SAFE_INTEGER. developer.mozilla.org
The parser this tool uses, and what it accepts: JSON.parse. developer.mozilla.org
The exact integer type that would avoid the rounding: BigInt. developer.mozilla.org

Every behaviour and every value on this page was measured against this tool as it is published, in a browser, on 14 October 2026. Where the page says what the tool does not do, that is a statement about this tool, not about JSON in general.

Frequently asked questions

Why did my ID number change?

Because formatting parses the number into a 64-bit float, which cannot hold integers above about nine quadrillion exactly. Measured: 12345678901234567890 comes back as 12345678901234567000, and the status still says Valid JSON. Use this tool to read and validate such a file, not to produce the version you will use. If you control the producer, send large ids as strings.

Can I use it to find duplicate keys?

No, and this is worth knowing before you try: it hides them. Measured, {"a":1,"a":2} formats to {"a": 2} with no warning. RFC 8259 says names in an object should be unique and that “many implementations report the last name/value pair only”. This is one of them.

Why is my file invalid when my editor accepts it?

You almost certainly have a comment, a trailing comma, a single-quoted string or an unquoted key. All four are valid JavaScript and none is valid JSON, and files like tsconfig.json use them by convention. The error message gives you a character position and a line and column, so start there.

Does it keep my key order?

Yes by default, which is not guaranteed by the format, since JSON objects are unordered. Measured: {"z":1,"a":2} keeps z first. Switch to Sort alphabetically before diffing two files that were written in different orders, so the diff shows real differences rather than ordering.

Why did 1e3 become 1000?

The number is reprinted from its parsed value, so exponent notation is expanded. The value is identical and the text is not, so a byte comparison against your original will differ. Negative zero becomes plain zero for the same reason.

Can it fix my broken JSON?

No. It reports the first problem with a position and stops. It will not add missing brackets, close strings or guess at intent, because a repair that guesses wrong is worse than an error.

Can it validate against a schema?

No. It checks that the document is well-formed JSON, not that it has the fields your system expects or that they are the right types. Those are different jobs and need a schema validator.

Is my JSON uploaded?

No. The parsing and formatting happen in your browser and nothing leaves the page. That matters here more than on most tools, because the JSON people need to format is often an API response or a config file with a key in it.

JSON Formatter & Validator