JSON Validator & Formatter
JSON is a deliberately small format, and almost every parse error comes from one of about six things it does not allow. This validates and reindents your document in the page, and the notes below cover the rules that catch people out.
How to use it
- Paste JSON into the input.
- It is parsed with the browser native JSON.parse and re-serialised with two-space indentation.
- A syntax error reports the character position where parsing stopped.
The six things JSON does not allow
JSON is a strict subset of JavaScript object literal syntax, and the differences are where errors come from.
In rough order of how often they cause a failed parse:
- Trailing commas. A comma after the last element of an array or object is legal in modern JavaScript and illegal in JSON. This is by far the most common error, and it usually appears after someone deletes the final entry by hand.
- Comments. Neither // nor /* */ is permitted. Configuration files that appear to contain comments are using JSONC or JSON5, which are different formats that a standard parser will reject.
- Single-quoted strings. Keys and string values must use double quotes. Unquoted keys are also invalid, even though JavaScript accepts them.
- NaN and Infinity. Both are valid JavaScript numbers and neither is valid JSON. Serialising them with JSON.stringify silently produces null, which is its own class of bug.
- Leading zeros and leading decimal points. 007 and .5 are both rejected; write 7 and 0.5.
- Unescaped control characters inside strings. A literal newline or tab in a string must be written as an escape sequence.
Duplicate keys are legal and dangerous
The JSON specification does not forbid an object from containing the same key twice, and it does not say what a parser should do about it. In practice almost every parser takes the last occurrence, but this is convention rather than a requirement.
The security consequence is real. If two systems in a request path parse the same document with parsers that disagree, an attacker can craft a payload where a validation layer sees one value and the layer that acts on it sees another. This has produced authentication bypasses in practice. Rejecting duplicate keys explicitly is the safe posture when parsing untrusted input.
Number precision is silently lossy
JSON does not distinguish integers from floats and places no limit on the size of a number. JavaScript represents all of them as IEEE 754 doubles, which are exact only up to 2 to the power of 53.
Parse a value like 9007199254740993 and you get 9007199254740992 back. There is no error and no warning. The identifiers most likely to exceed the threshold are exactly the ones where silent corruption matters: Twitter-style snowflake IDs, large database primary keys, and financial account numbers.
The standard workaround is to transmit such values as strings. It is inelegant and it works everywhere.
What formatting does and does not tell you
A successful format proves the document is syntactically valid JSON. It says nothing about whether the structure is the one your application expects. A response missing a required field, or carrying a string where a number belongs, formats perfectly.
Structural checking is what JSON Schema is for, and it is worth running at any boundary where JSON enters your system from outside it.
One detail on ordering: the specification defines objects as unordered, but every mainstream parser preserves insertion order in practice, and this document is re-serialised in the order it was parsed.
At a glance
| Parser | Native JSON.parse |
|---|---|
| Output | Two-space indentation, key order preserved |
| Errors | Reported with character position |
| Transmitted | Nothing |
Frequently asked questions
Why does my JSON fail when it looks fine?
Check for a trailing comma before a closing brace or bracket first; it is the most common cause. After that, look for comments, single-quoted strings, and unquoted keys, all of which are valid JavaScript and invalid JSON.
Can JSON contain comments?
No. Files that appear to are JSONC or JSON5, which standard parsers reject. If you need annotated configuration, YAML or TOML supports comments natively.
Why did my large ID number change?
JavaScript numbers are IEEE 754 doubles and lose precision beyond 2^53. Integers larger than that are silently rounded. Transmit them as strings.
Does formatting validate against a schema?
No. It confirms the syntax is valid JSON. Checking that the structure matches what your application expects requires JSON Schema or an equivalent validator.
Read more
Formatting and encoding — Pretty-printing catches bugs, Base64 costs 33 percent, and escaping applied in the wrong context prevents nothing.