Skip to main content

JSON Formatter and Validator

Format, validate and inspect JSON in your browser. Detects duplicate keys and precision loss on large integers that other formatters silently corrupt.

Your data never leaves the browserUpdated: July 2026
Indent

Key Takeaways

  • JSON.parse silently corrupts large integers: 9007199254740993 is read back as 9007199254740992, and the original value cannot be recovered.
  • Duplicate keys are resolved last-one-wins, and most validators still report the document as simply "valid".
  • This tool reports both conditions with the line number where they occur.
  • Nothing you paste leaves your browser; formatting happens entirely on your machine.

Why formatting JSON is harder than it looks

Making a JSON document readable looks like a two-line job: parse it, then stringify it with indentation. The catch is that data can be lost between those two steps, and the loss produces no error at all. Load the sample above to see both failure modes at once.

Precision loss on large integers

JavaScript numbers are IEEE-754 double-precision floats, which represent integers exactly only up to 2^53 - 1 (9007199254740991). Parse anything larger and it is rounded to the nearest representable value:

javascript
JSON.parse('{"id":9007199254740993}')// { id: 9007199254740992 }  <-- last digit changed JSON.parse('{"amount":1e400}')// { amount: Infinity }JSON.stringify({ amount: Infinity })// '{"amount":null}'  <-- the value disappeared entirely

This is not a theoretical concern. Snowflake-style identifiers (Twitter, Discord), BIGINT primary keys, and amounts stored in minor units all land in this range comfortably. Format an API response, copy the result, and you may be holding a different identifier than the one you were sent.

Warning

The fix is to carry large identifiers as JSON strings. If you design the API, quote your 64-bit ids. If you only consume it and cannot change the producer, parse with a library that maps numbers to BigInt instead of Number.

Duplicate keys

RFC 8259 recommends unique keys within an object but does not require them. Most parsers keep the last occurrence and silently discard the earlier ones:

javascript
JSON.parse('{"role":"reader","role":"admin"}')// { role: 'admin' }  <-- "reader" is gone

In hand-merged config files and template-generated payloads this becomes a real security problem. If two systems read the same document with different precedence (one taking the first value, another the last), their authorization decisions diverge. This tool lists every duplicate key with its line number.

Common parse errors

InputWhy it is invalidFix
{'name': 'Ada'}JSON accepts double quotes only{"name": "Ada"}
{"a": 1,}Trailing commas are not valid JSON{"a": 1}
{"a": undefined}undefined is not a JSON value{"a": null}
{a: 1}Keys must be quoted{"a": 1}
// a commentJSON has no comment syntaxRemove it, or use JSONC
The overwhelming majority of JSON.parse failures reduce to one of these five patterns.

An invisible BOM at the start of a file is another frequent trap: documents produced on Windows may begin with \uFEFF, which JSON.parse rejects. This tool strips the BOM automatically.

Unicode and encoding

JSON text is Unicode, so non-ASCII characters can be written directly: {"city":"İstanbul"} is perfectly valid. Some systems escape them to \u0130 instead; both forms carry identical data and differ only in presentation. When characters do break, the cause is almost always a file read with the wrong encoding rather than the JSON itself.

Frequently Asked Questions

Is the data I paste sent to a server?
No. Formatting, validation and every check run in JavaScript in your browser. No network request carries your input; once the page has loaded you can disconnect entirely and the tool keeps working.
Can I use comments in a JSON file?
Standard JSON has no comments. If you need them in configuration, use a superset such as JSONC (used by VS Code settings), JSON5, or YAML. This tool expects standard JSON.
Can I format a very large file?
Files of a few megabytes are handled comfortably. Much larger inputs may make the tab unresponsive briefly, because parsing happens on a single thread. For files in the tens of megabytes, a command-line tool such as jq is a better fit.
Should I indent with spaces or tabs?
It makes no technical difference, since whitespace is insignificant in JSON. Follow your team convention. For files committed to a repository, consistency matters far more than the choice itself, since mixed indentation produces noisy diffs.
Why do other validators call a document with duplicate keys valid?
Because most of them only call JSON.parse and check whether it threw. Once parsing succeeds the evidence of a duplicate key is already gone. This tool runs a separate scan over the raw source text to recover it.