JSON Formatting & Validation
Why the small syntax errors are the ones that actually break things
JSON (JavaScript Object Notation, formalized as RFC 8259) has become the default data-interchange format for APIs, config files, and app-to-app communication because it's simple, human-readable, and maps cleanly onto the data structures most languages already have — objects/dictionaries and arrays. That simplicity is also why JSON errors are so common and so easy to miss by eye: JSON's grammar is strict in ways that don't match how people naturally write. Trailing commas after the last item in an array or object aren't allowed (unlike JavaScript object literals, which is a frequent source of confusion), keys must be double-quoted strings (not single-quoted, not bare), and there's no support for comments at all.
A missing brace or an extra comma buried in a large, minified JSON payload — say, an API response someone's debugging, or a config file that's supposed to feed a build pipeline — can be genuinely hard to spot without a tool that pinpoints exactly which line and column broke the parse. That's the actual job a JSON formatter does: not just making it pretty, but telling you precisely where it's wrong.
Braceful formats, minifies, and validates JSON entirely offline, with errors reported down to the exact line and column, and a collapsible tree view for exploring deeply nested structures without losing your place.
The app
Frequently asked questions
What are the most common JSON syntax errors?
Trailing commas after the last item in an array or object (valid in JavaScript object literals, invalid in strict JSON), unquoted or single-quoted keys, mismatched or missing closing braces/brackets in deeply nested structures, and using JavaScript-only values like `undefined` or trailing comments — none of which are valid JSON. Most of these are easy to introduce by hand-editing JSON that was copied from JavaScript source code, since the two look almost identical but follow different rules.
What's the difference between JSON and JavaScript object literals?
JSON is a text-based data format with a strict, minimal grammar; JavaScript object literal syntax is a superset that JSON's grammar was originally derived from. JavaScript allows unquoted keys, single quotes, trailing commas, comments, and function values — none of which are valid in real JSON. Code that looks like JSON but was actually written as a JavaScript literal will often fail a strict JSON parser.
Why does formatting JSON matter beyond readability?
Pretty-printing with consistent indentation makes nested structure visible at a glance, which is often the fastest way to spot a misplaced brace or an array that's one level too deep. Minifying (removing whitespace) matters for the opposite reason — reducing payload size for anything sent over a network, like an API response or a config bundled into an app.
Is it safer to validate JSON on-device instead of pasting it into a web tool?
It can matter more than people assume — JSON payloads people paste into online formatters often contain API keys, auth tokens, or other sensitive fields from a real request or config file, and a web-based tool means that data is sent to someone else's server, even briefly. An on-device validator never transmits what you paste anywhere.