{ } JSON Formatter & Validator
Format and validate JSON in your browser, nothing uploaded. Covers the six value types, why trailing commas fail, and the 2^53 precision trap on large IDs.
What JSON Formatter & Validator Does
JSON is a text format for structured data, defined by RFC 8259 and ECMA-404. It has six value types and no more: object, array, string, number, boolean and null. Everything people expect it to have beyond that — comments, trailing commas, dates, integers distinct from floats — is absent by design.
Formatting adds indentation and line breaks so a human can read it. Validating checks the document against the grammar and reports where it breaks. Both run entirely in your browser here; nothing you paste is transmitted, which matters because API responses routinely contain tokens and personal data.
The subtle failure mode is not a syntax error, which you will see, but a number that quietly changes value. JSON does not distinguish integers from floating point, and most parsers use IEEE 754 doubles — so an ID above about 9 quadrillion comes back different from how it went in, with no error at all.
How to Use JSON Formatter & Validator
- Paste your JSON data into the input area
- Click "Format" to beautify with indentation
- View any validation errors highlighted in the output
- Use "Minify" to compress or "Copy" to copy the result
Formula Used by JSON Formatter & Validator
The safe integer limit
safe_range = ±(2^53 − 1) = ±9,007,199,254,740,991
- 2^53
- The precision limit of an IEEE 754 double, which is what JavaScript and most JSON parsers use for every number
Worked example
A 64-bit database ID or a platform snowflake ID: 9007199254740993.
- JSON.parse('{"id":9007199254740993}') → 9007199254740992
- Re-serializing gives {"id":9007199254740992}
Result: The value silently changed by 1, with no error raised. Send large IDs as strings.
The Six JSON Value Types
The complete list. Anything else must be encoded as one of these.
| Type | Example | Notes |
|---|---|---|
| Object | {"a": 1} | Unordered key/value pairs; keys must be double-quoted strings |
| Array | [1, 2, 3] | Ordered; may mix types |
| String | "text" | Double quotes only. Single quotes are invalid |
| Number | 42, -1.5, 2e10 | No distinction between integer and float. No NaN, no Infinity, no leading + |
| Boolean | true, false | Lowercase only |
| Null | null | Lowercase only |
Source: RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format
What JSON Does Not Have
Every entry here is a frequent cause of "why is my JSON invalid". None of them are supported by the specification.
| Not supported | Why it fails | What to do instead |
|---|---|---|
| Comments | No comment syntax exists in the grammar | Use a "_comment" key, or JSONC if your parser allows it |
| Trailing commas | {"a":1,} is a syntax error | Remove it; most formatters flag the position |
| Single quotes | 'text' is not a JSON string | Use double quotes |
| Unquoted keys | {a:1} is invalid | Quote every key |
| NaN and Infinity | Not in the number grammar | Use null, or a string sentinel |
| Dates | No date type | ISO 8601 strings (RFC 3339) |
| Integers vs floats | One number type only | Send large integers as strings |
Common Parse Errors and What Causes Them
| Message | Usual cause |
|---|---|
| Unexpected token } in JSON | A trailing comma before the closing brace |
| Unexpected token ' in JSON | Single quotes instead of double |
| Unexpected end of JSON input | Truncated response, or an empty body |
| Unexpected token < in JSON | You received HTML — usually an error page, not JSON |
| Bad control character in string | A raw newline or tab inside a string; escape as \n or \t |
| Duplicate keys, no error | The spec does not forbid them; most parsers silently keep the last |
How to Read Your Result
Send large IDs as strings
This is the single most valuable habit in JSON API design. Any 64-bit identifier — database bigints, platform snowflake IDs, financial reference numbers — exceeds what a double can represent exactly. Several large platforms learned this publicly and now return both a numeric id and a string id_str for exactly this reason. If a value is an identifier rather than a quantity, quote it.
A trailing comma is the most common syntax error
It is valid in JavaScript object literals and invalid in JSON, so it survives code review and fails at parse time. JSON5 and JSONC permit it, but neither is JSON — if you are hand-editing a config file that allows trailing commas, check which format the consumer actually parses.
"Unexpected token <" means you got HTML
Almost always a server returned an error page, a login redirect, or a proxy notice instead of JSON, and the parser is choking on the opening angle bracket of <!DOCTYPE. Check the HTTP status code and the response body before debugging the parser.
Duplicate keys are not an error
RFC 8259 says names within an object SHOULD be unique, but does not require it, and behavior when they are not is explicitly undefined. In practice most parsers keep the last occurrence and discard the earlier one silently. That makes duplicate keys a genuine security consideration when two systems parse the same document differently.
Limitations & Accuracy Notes
- Formatting and validation happen in your browser and nothing is transmitted. Even so, treat pasting production tokens into any web tool as a habit worth avoiding.
- Very large documents are limited by browser memory. Multi-hundred-megabyte files should be processed with a streaming parser rather than a web page.
- Numbers are handled with JavaScript's native parser, so integers beyond ±(2^53 − 1) lose precision here exactly as they would in your application. This is the specification working as designed, not a fault in the tool.
- This validates against JSON proper. JSON5, JSONC, NDJSON and YAML are different formats and will be reported as invalid.
- Key order is preserved on formatting but carries no meaning — JSON objects are explicitly unordered.
Frequently Asked Questions
What is JSON?
How do I format JSON?
Can this tool validate JSON?
Is my JSON uploaded anywhere?
Why does my JSON fail to parse when it looks fine?
What is the difference between formatting and minifying?
Does it preserve the order of keys?
Can it handle very large files?
Why are large numbers changing slightly?
References & Further Reading
- RFC 8259 — The JSON Data Interchange Format — The normative IETF specification, including the duplicate-key guidance
- ECMA-404 — The JSON Data Interchange Syntax — The parallel Ecma standard for the grammar
- json.org — Introducing JSON — The original grammar diagrams