The JSON Formatter and Validator takes raw JSON and returns it beautifully indented, minified to a single line, or simply checked for validity, with structural statistics about the data, entirely in your browser. Paste JSON, choose format, minify, or validate, pick an indentation of two spaces, four spaces, or tabs, and read the result or the precise parse error.
How It Works
The text is parsed with the browser's JSON parser, the same strict grammar every JSON consumer uses. Valid input is re-serialized with your chosen indentation (or with no spacing at all in minify mode), and the tool computes statistics on the parsed value: the number of top-level keys, the maximum nesting depth, how many arrays the structure contains, and the raw versus minified sizes in characters. Invalid input returns the parser's error message instead of partial output, so you fix syntax against the real grammar rather than a guess.
Parameters
| Input | Required | Meaning | |---|---|---| | JSON text | Yes | The document to process | | Mode | Yes | Format, minify, or validate only | | Indent | No | 2 spaces (default), 4 spaces, or tab, for formatted output |
Worked example
Take this compact but valid document: { "name": "Ada", "tags": ["dev", "seo"], "nested": { "x": 1 } }. It is 63 characters as typed. Formatting with two-space indentation expands it into a readable fourteen-line layout; minifying strips it to 52 characters, { "name":"Ada", ... } without spaces (shown with spaces here for legibility). The statistics report 3 top-level keys, a maximum depth of 2, and 1 array. Validate mode would return no text, just confirmation and the same statistics, which is the right choice when a pipeline rejects a payload and you only need to know whether the JSON itself is the problem.
Common JSON errors and what they mean
Trailing commas after the last item are the most frequent failure: JSON, unlike JavaScript, forbids them. Single-quoted strings are invalid; keys must be double-quoted; comments are not allowed anywhere; and numbers cannot carry leading plus signs or bare leading zeros. Control characters inside strings must be escaped, which is why pasted text containing raw newlines inside a string value fails. The parser's error message names the problem area; count to the reported position and look for the quote, comma, or bracket that breaks the pattern. Because object keys are compared as strings, a duplicated key parses without error and silently keeps the last value, a validity trap no parser will flag for you.
Format, minify, validate: choosing the mode
Format for humans: code review, config inspection, debugging API responses. Minify for transport and storage: the 63-to-52 character saving in the toy example becomes megabytes across logged API payloads, though production APIs should minify at the source rather than by hand. Validate when you only need a yes or no with statistics, for example checking a webhook payload sample or a fixture file before committing it. None of the modes changes the data itself: formatting is purely whitespace, and any tool that alters values while "formatting" is a bug, not a feature.
Privacy and safety
Processing happens locally in your browser; the JSON is not sent to a server, which matters because real payloads contain tokens, emails, and personal data. Local processing is not a license to be careless: avoid pasting production secrets into any shared machine or screen-shared session, and redact credentials before putting formatted output into tickets or chat logs, where it tends to live forever.
Limitations
The tool validates syntax, not schema: a document can be perfectly valid JSON and completely wrong for your API (missing fields, wrong types, misspelled keys). It handles one document at a time, and extremely large inputs are bounded by browser memory. JSON5, JSONC with comments, and JavaScript object literals are intentionally rejected as invalid JSON.
Numbers and dates: the two silent traps
JSON numbers are double-precision floats in most parsers, so integers above 2^53 lose precision silently: an ID such as 9007199254740993 can come back as 9007199254740992 after a parse-and-format round trip. APIs that emit 64-bit IDs should quote them as strings; if yours does not, avoid round-tripping payloads through any formatter before comparing IDs. Dates have the opposite problem: JSON has no date type at all, so dates travel as strings (usually ISO 8601) and every consumer interprets them by convention. A validator can confirm the string is well-formed JSON; it cannot confirm the date means what your API expects, which is a schema question, not a syntax one.
JSON lines and other neighbours
Streams of logs and events often use JSON Lines (one complete JSON value per line), which is not itself a single valid JSON document and will fail validation here until you wrap it in an array or process it line by line. Config files with comments are JSONC, common in editor settings, and equally invalid as strict JSON. Knowing which dialect you are holding explains most "valid file, invalid JSON" confusion: the formatter enforces the strict core grammar that APIs and data pipelines actually exchange.
Frequently Asked Questions
Why is my JavaScript object invalid JSON?
Because JSON is a stricter subset: keys must be double-quoted, strings must be double-quoted, and trailing commas and comments are forbidden. Convert the object with JSON.stringify in the console, or fix those three things manually.
Does formatting change my data?
No. Whitespace between tokens is not data. Parsing the formatted and minified versions yields identical values, which is exactly what the matching statistics confirm.
What does maximum depth tell me?
How deeply the structure nests. Deep nesting (beyond eight to ten levels) often signals an API design or export artifact worth questioning, and some parsers and databases impose depth limits it warns you about early.