The Complete Guide to JSON Validation
JSON — JavaScript Object Notation — has become the default data interchange format for the modern web: every REST API, every configuration file, every webhook payload, every NoSQL database document, every cloud-provider pipeline definition speaks it. JSON’s simplicity is what makes it universal — six data types, two structural types, no schema required — and that same simplicity is what makes validating it so frequently necessary: there is no compiler to catch your typos, no schema enforced at parse time by definition, and the parser’s error messages are notoriously terse. A JSON validator is the safety net that catches malformed JSON before it reaches production: missing commas, unquoted keys, trailing commas, single-quoted strings, and the dozen other small errors that turn a 50-kilobyte payload into a 500 server error.
1. What a validator actually does
A JSON validator parses the input against the JSON grammar and reports whether the input is well-formed. If it is, the validator reports structural statistics about the document — how many keys, how many arrays, the maximum nesting depth — that give a quick sense of the shape of the data without reading it line by line. If it is not, the validator reports the syntactic error and the position at which it occurred, so you can navigate directly to the broken byte rather than scanning the entire document. Both outcomes are useful: the success outcome tells you it is safe to ship the JSON downstream; the failure outcome points you at the bug you need to fix.
2. The most common JSON errors
- Trailing comma — the single most common error, often from hand-editing a JSON file. JSON forbids the trailing comma after the last item in an object or array, unlike JavaScript where it is allowed. The parser stops at the comma and reports the error position so you can delete it.
- Single-quoted strings — JSON requires double quotes for all strings and string keys. Pasting JavaScript-style code into a JSON file produces a wall of these errors.
- Unquoted keys —
{name: 'value'}is valid JavaScript but invalid JSON. JSON requires{"name": "value"}. - Comments — JSON strictly forbids
//and/* */comments. Many JSON-with-comments extensions exist (JSON5, JSONC) but plain JSON rejects them. - Last-but-one comma omission — the opposite of the trailing comma: you forget the comma between two items and the parser reads the second item as part of the first.
- NaN / Infinity / undefined — JavaScript literals that have no JSON representation. Use
nullor omit the key.
3. Validation vs schema validation — knowing the difference
There are two distinct questions about a JSON document: is it well-formed JSON (syntactic validity) and does it match my expected shape (schema validity). This tool answers the first question. The second requires JSON Schema— a separate specification that lets you define the expected keys, types, and constraints of a JSON document and validate a given document against that definition. Both matter, but they answer different questions: a validator tells you the document is structurally parseable; a schema validator tells you the document has the shape your code expects. For most informal workflows, the validator is the daily-use tool; for production pipelines and API contracts, a schema validator is the right companion.
4. Tree and format views — when reached-for analyses
Once a JSON document passes validation, two further features become useful: a tree view and a pretty-printed format view. The tree view collapses nested objects and arrays into an navigable outline — ideal for inspecting a large, deeply-nested payload without scrolling through ten thousand lines of raw text. The format view re-emits the document with consistent indentation so it is readable in any editor, replacing the one-line minified form or the inconsistent-form manuscript with a clean, uniform representation. Both views become available only after the document validates — the tool refuses to format invalid input.
5. Statistics — the four numbers that summarise a document
The size-and-shape statistics — file size, nesting depth, key count, array count — give you a quick sense of a JSON document without reading it. A 200 MB JSON file with a nesting depth of 3 and a key count in the low thousands is a flat-list-of-records shape (typical of database exports). A 50 KB JSON file with a nesting depth of 14 is a deeply-structured configuration. Both patterns are valid; the statistics tell you which you are looking at so you can pick the right inspection strategy (flatten vs dive).
6. Why validation belongs in the browser
JSON often contains customer records, internal endpoint definitions, or production configuration values you would not want exposed. Uploading it to a remote validator is a real confidentiality risk: the server sees the entire document and may store it. This tool runs the validator entirely in your browser using the built-in JSON parser, so nothing leaves your device. There is no upload, no retention, no telemetry. The JSON you validate stays on the machine you validated it on — and that lets you validate even customer data, internal payloads, and secret configuration with no second thought.
Conclusion
JSON validation is the inexpensive safety net that catches the small syntactic mistakes that would otherwise break production at the worst moment. With both a successful-validation outcome (with statistics, tree view, and pretty-printed output) and a failure outcome (with position-precise error messages) the tool covers the full validation workflow in one page. Pair it with a JSON Schema validator for production contracts and the JSON Formatter for cleaning up hand-written files, and the entire JSON-handling surface is covered.