JSON Viewer Developer Tool

What JSON is, and why formatting matters

JSON (JavaScript Object Notation) is a text-based format for representing structured data: objects made of key/value pairs, arrays, strings, numbers, booleans, and null. It has no concept of comments, dates, or trailing whitespace — just those few data types, nested as deeply as needed. That simplicity is exactly why it became the default format for API responses and configuration files: almost every language can parse and produce it without a bespoke library.

The catch is that valid JSON says nothing about how it's laid out on the page. A server response or a minified config file is often a single unbroken line, because whitespace outside of strings has no meaning to the parser. That's efficient to transmit but nearly unreadable to a human trying to find one field in a payload with fifty keys nested four levels deep. Indentation, line breaks, and consistent key ordering don't change the data at all — they only change how quickly a person can scan it. That's the entire job of a JSON viewer: take a blob of syntactically correct but visually flat text and lay it out as a tree you can expand, collapse, and read.

Common syntax errors

JSON's strictness is also where it trips people up, usually because it looks close enough to a JavaScript object literal to invite the same shortcuts. A few mistakes account for most parse failures:

Trailing commas. {"a": 1, "b": 2,} is invalid — the comma after the last value has nothing to separate. JavaScript object literals tolerate this; JSON does not.

Unquoted keys. {name: "Ian"} fails because JSON requires every key to be a double-quoted string, not a bare identifier.

Single quotes. {'name': 'Ian'} is invalid for the same reason — JSON strings must use double quotes, full stop. Single quotes are a JavaScript convenience the JSON spec never adopted.

A validator's real value is pinpointing exactly where parsing broke, rather than leaving you to eyeball a wall of text for a missing brace. This tool reports the parser's error message directly, including the position it stopped at, so you can jump straight to the offending character instead of guessing.

JSON vs JSON5 and JSONC

Because strict JSON forbids comments and trailing commas, more forgiving supersets have emerged for use cases where humans, not just machines, edit the file directly. JSONC (JSON with Comments) adds // and /* */ comments and is used by tools like VS Code for its own settings files. JSON5 goes further, allowing unquoted keys, trailing commas, single-quoted strings, and a few other JavaScript-like conveniences. Both are strict supersets meant for hand-edited config, and neither is valid JSON on its own — a standard JSON parser (including this tool) will reject a JSON5 or JSONC file until the comments and trailing commas are stripped out.

Common use cases

The two situations where this tool tends to get used most are debugging API responses and inspecting configuration. When an endpoint returns an error or an unexpected shape, pasting the raw response in and browsing it as a tree is usually faster than adding console.log statements or re-running the request with a formatter attached. For configuration — a package.json, a build manifest, an exported settings file — the same tree view makes it easy to confirm a key exists, check its nesting, or spot a value that's the wrong type (a string where a number was expected, for instance) at a glance.