JSON Formatter
Format, validate, and minify JSON online. Pretty-print API payloads, catch syntax errors, and keep your data in the browser.
Formula
Format: JSON.stringify(JSON.parse(input), null, 2) | Minify: JSON.stringify(JSON.parse(input))
The tool first parses the input to validate JSON syntax, then serializes it either with indentation or as a compact one-line string.
Worked Examples
Example 1: Format an API response
Problem:Make a single-line API response easier to review.
Solution:Input: {"user":{"id":123,"name":"John"},"status":"active"} Formatted output: { "user": { "id": 123, "name": "John" }, "status": "active" }
Result:Nested objects become readable and easier to debug.
Example 2: Catch invalid syntax
Problem:Why is this JSON invalid: {name: "John", "age": 30,}?
Solution:Two issues exist: the key name is unquoted and there is a trailing comma after the last property. Valid JSON must use double-quoted keys and cannot end an object or array with an extra comma.
Result:The formatter surfaces the parse error before you ship broken JSON.
Example 3: Minify for production
Problem:Shrink a formatted configuration object before deployment.
Solution:Pretty JSON keeps the structure readable during editing. Minified JSON removes line breaks and spaces so the same data takes fewer bytes over the network.
Result:Same data, smaller payload.
Frequently Asked Questions
Why format JSON?
Formatted JSON adds indentation and line breaks so you can inspect nested objects, arrays, and keys quickly. It is much easier to debug than a single minified line.
Why minify JSON?
Minified JSON removes unnecessary whitespace to reduce payload size. That makes network transfers and storage more efficient, especially in production environments.
What makes JSON invalid?
Common errors include trailing commas, unquoted keys, single quotes instead of double quotes, missing braces or brackets, and unescaped special characters inside strings.
Can JSON include comments?
Standard JSON does not allow comments. If you need comments in configuration data, use a different format such as YAML or a JSON-compatible extension like JSON5.
Does this formatter send my JSON to a server?
No. The formatter runs in your browser. Your JSON is parsed, formatted, and validated client-side.
Why did my large ID number change after formatting?
JavaScript parses every JSON number into an IEEE 754 double, which holds integers exactly only up to 2^53 - 1, or 9007199254740991. A 64-bit database key or snowflake ID above that is silently rounded on parse and no error is raised. The fix is at the producing end: serialise large identifiers as JSON strings, not numbers.
What does the indent setting actually change?
Only the whitespace between tokens. Pretty-printing with two-space indentation and minifying to a single line produce byte-for-byte identical data once parsed, because whitespace outside of string values is insignificant in JSON. Format for reading and diffing; minify for transmission and storage.
How should I handle dates in JSON?
JSON has no date type, so every timestamp is really a string or a number. The safe convention is ISO 8601 in UTC, such as 2026-03-14T09:30:00Z, which sorts correctly as plain text and parses in every language. Avoid locale-formatted strings, and prefer explicit ISO strings to Unix epoch integers when humans will read the payload.
What happens if the same key appears twice in an object?
RFC 8259 says names within an object should be unique but does not forbid duplicates, and leaves parser behaviour undefined. JavaScript keeps the last occurrence and discards the earlier ones silently. Other languages differ - some keep the first, some raise an error, some return a list. Never depend on it; treat a duplicate key as a bug in whatever produced the document.
Is JSON Lines the same as JSON?
No. JSON Lines, also called NDJSON, puts one complete JSON value on each line of a file with no wrapping array and no commas between records. It is not valid JSON as a whole document, but it streams: a consumer can process one line at a time without loading the file into memory. That makes it the usual choice for logs and large exports, where a single enormous JSON array would not fit.
Background & Theory
JSON is a text format for structured data with exactly six value types and no extensibility mechanism. Its entire grammar fits on one page, which is the source of both its interoperability and its limitations.
The six value types
- object - an unordered set of name/value pairs in curly braces, where every name is a double-quoted string
- array - an ordered sequence in square brackets
- string - double-quoted, with backslash escapes for quote, backslash, forward slash, and the control characters; any other character may be written as \uXXXX
- number - decimal, with optional fraction and exponent
- boolean - the literals true and false, lowercase
- null - the literal null, lowercase
Rules that trip people up
- Keys must be double-quoted strings. Bare identifiers are valid JavaScript but invalid JSON.
- Single quotes are never valid, for keys or values.
- A trailing comma after the last element of an object or array is a syntax error.
- Comments do not exist in the format at all.
- Numbers may not have a leading plus, a leading zero on an integer, or a trailing decimal point, and NaN, Infinity and hexadecimal literals are all invalid.
- Dates have no native type. Every timestamp in JSON is really a string, conventionally ISO 8601.
The precision trap
JSON numbers have no size limit in the specification, but JavaScript parses every number into an IEEE 754 double. Integers stay exact only up to 2^53 - 1, which is 9007199254740991. A 64-bit database identifier or a Twitter-style snowflake ID above that threshold is silently rounded on parse - the value changes and no error is raised. The standard workaround is to serialise large identifiers as strings.
Duplicate keys
RFC 8259 says the names within an object should be unique but does not require it, and leaves the behaviour of parsers that receive duplicates undefined. JavaScript keeps the last occurrence; other languages differ, and some raise an error. Never rely on it.
Typical use cases
- API request and response payloads, and JSON Web Token headers and claims
- Configuration files such as package.json and tsconfig.json
- localStorage, sessionStorage and application state
- Newline-delimited JSON (NDJSON) for log lines and streaming records
- Schema.org structured data embedded in web pages as JSON-LD
History
JSON was not invented so much as noticed. Around 2001 Douglas Crockford, working on a browser-to-server messaging system, observed that a subset of JavaScript object literal syntax was already a complete, self-describing data format that every browser could parse natively. He published the grammar at json.org in 2002 - a single page with railroad diagrams, because the entire specification fits on one.
Displacing XML
The dominant interchange format at the time was XML, carried through the XMLHttpRequest object that made AJAX possible. XML was verbose, required a parser library, and produced a document tree that had to be walked. JSON arrived as roughly a third of the bytes, mapped directly onto native arrays and objects, and needed no library at all in a browser. As public web APIs proliferated after 2005, most shipped JSON first and XML as a legacy option, and by the early 2010s many shipped JSON only.
Standardisation
Formal specification came later than adoption, which is unusual. RFC 4627 was published as an informational document in 2006. ECMA-404 defined the syntax in 2013, and the IETF replaced RFC 4627 with RFC 7159 in 2014 and then RFC 8259 in December 2017, which was designated Internet Standard 90. The two bodies deliberately aligned their grammars: ECMA-404 describes the syntax, RFC 8259 adds interchange rules such as requiring UTF-8 encoding between systems that have not otherwise agreed.
The parts that were left out
Crockford declined to add comments to the format, on the grounds that they had been used to carry parsing directives in other formats and would break interoperability. He also fixed the specification permanently, arguing that a format which never changes cannot break. Both decisions are why JSON5, JSONC and YAML exist as separate formats rather than as JSON revisions.