JSON Formatter

JSON (JavaScript Object Notation, RFC 8259) is a text format for structured data. Despite its name, JSON is language-independent and used across virtually every programming language and API. A valid JSON document is one of six types:

• String — double-quoted Unicode text. Supports escape sequences: \" \\ \/ \b \f \n \r \t \uXXXX. Single quotes are not valid.
• Number — integer or decimal. Supports scientific notation (1.5e10). No leading zeros, no hex, no NaN, no Infinity. Octal (0777) is not valid.
• Boolean — lowercase true or false only. True, TRUE, and yes are not valid.
• Null — lowercase null only. None, undefined, and nil are not valid.
• Object — unordered set of key-value pairs. Keys must be double-quoted strings. Duplicate keys are technically allowed by the spec but discouraged — most parsers use last-wins behavior.
• Array — ordered list of values. Elements can be any type, including mixed types.

Trailing commas. The most common JSON error. Unlike JavaScript, JSON does not allow a comma after the last element: [1, 2, 3,] is invalid. Remove the trailing comma.

Comments. JSON has no comment syntax. Lines starting with // or blocks wrapped in /* */ will cause parse errors. Use JSONC or JSON5 if you need comments.

Single quotes. JSON requires double quotes for both keys and string values. {'key': 'value'} is invalid — use {"key": "value"}.

Unquoted keys. Object keys must be double-quoted strings. {name: "test"} is valid JavaScript but invalid JSON.

Number precision. JSON numbers are parsed as IEEE 754 double-precision floats. Integers beyond 2⁵³ - 1 (9,007,199,254,740,991) lose precision. APIs handling large IDs (like Twitter/X snowflake IDs) often encode them as strings for this reason.

Unicode escapes. The \uXXXX escape represents a UTF-16 code unit. Characters outside the Basic Multilingual Plane (like emoji) need surrogate pairs: \uD83D\uDE00 for 😀. Most editors handle this automatically, but hand-editing Unicode escapes is error-prone.

Duplicate keys. RFC 8259 says object keys "SHOULD be unique" but doesn't forbid duplicates. In practice, most parsers silently use the last value for a duplicate key. Some security vulnerabilities have exploited inconsistent duplicate-key handling between parsers.

Deeply nested structures. The spec sets no depth limit, but most parsers impose one (e.g., Python's json module defaults to 100). Extremely deep nesting can cause stack overflows in recursive parsers.

BOM and encoding. JSON must be UTF-8 (RFC 8259). A byte order mark (BOM, \xEF\xBB\xBF) at the start of a file will cause most parsers to reject it. Some tools add a BOM when saving UTF-8 files — remove it if you get an "unexpected token" error at position 0.

Whitespace. Only four characters count as insignificant whitespace in JSON: space (0x20), tab (0x09), newline (0x0A), and carriage return (0x0D). Other whitespace characters (like non-breaking space, 0xA0) inside strings are valid content but will cause errors if used outside strings.

JSON vs JSONC. JSONC (JSON with Comments) allows // and /* */ comments. Used by VS Code settings, TypeScript tsconfig.json, and other config files. Not valid JSON — most APIs won't accept it.

JSON vs JSON5. JSON5 extends JSON with unquoted keys, single-quoted strings, trailing commas, hex numbers, multi-line strings, comments, and more. Common in config files but not interchangeable with JSON.

JSON vs YAML. YAML is a superset of JSON (valid JSON is valid YAML). YAML adds indentation-based nesting, comments, anchors, and more types. YAML is more human-writable but more complex to parse and has a larger attack surface. JSON is the standard for APIs; YAML is common for configuration.

JSON vs TOML. TOML uses [sections] and key = value syntax with native date/time support. Popular for config files (Cargo.toml, pyproject.toml). Simpler than YAML but less expressive than JSON for deeply nested data.