Common JSON errors and how to fix them
- Trailing commas — JSON does not allow a comma after the last item in an object or array. Remove the last comma.
- Single quotes — JSON requires double quotes for both keys and string values. Replace single quotes with double quotes.
- Unquoted keys — Unlike JavaScript objects, JSON keys must always be wrapped in double quotes.
- Comments — JSON does not support comments. Remove any // or /* */ before validating.
JSON isn't quite a JavaScript object
JSON looks like a JavaScript object literal, which is exactly why the two get confused. JavaScript objects allow single quotes, unquoted keys, comments, trailing commas, and values like undefined or functions — JSON allows none of that. It's a stricter, language-independent text format that happens to share JavaScript's object syntax as its starting point, which is also why it pastes cleanly into JavaScript but doesn't always paste cleanly back out.
JSON is a data format, not a programming language
JSON is often mistaken for a programming language, but it's just a lightweight, language-independent data interchange format — a way of structuring data as text, not a way of writing logic. The same JSON file parses natively in Python, Java, PHP, JavaScript and virtually every other language, which is exactly why it's become the default format for API responses and config files across completely different tech stacks.
Formatting vs. minifying
Formatted (pretty-printed) JSON adds indentation and line breaks purely for human readability — useful when debugging an API response or reading a config file. Minified JSON strips all of that whitespace, producing a smaller file with identical data, which is what you actually want for anything sent over a network or stored where file size matters. Both represent exactly the same data; the choice is about who's going to read it next, a person or a machine.
Why the error message points to the wrong line
Most JSON parsers report an error at the position where they realized something was wrong, not where the actual mistake is — a trailing comma typically gets flagged at the closing brace or bracket that follows it, not at the comma itself. If a validator points at a line that looks perfectly fine, check the line immediately before it first. This is the single most common source of "but there's nothing wrong here" confusion when debugging JSON by eye.
Reading deeply nested API responses
Real API responses — from a payments processor, a maps service, a CRM — often nest data several levels deep, wrapping the actual value you want inside layers of surrounding objects and arrays. Formatting the raw response first, the way this tool does, is the first step to making that navigable at all: proper indentation turns an unreadable wall of braces into a structure you can actually trace by eye. For anything nested more than five or six levels deep, it's usually faster to pull the specific sub-object you care about out into its own formatted block than to keep scrolling through the full structure looking for it.
Validating structure, not just syntax
Valid JSON and correctly-shaped JSON are two different problems. This tool catches syntax errors — a trailing comma, a missing quote — but it can't tell you that a field your code expects is missing, or that a value came back as text when your code expects a number. That's what tools like JSON Schema exist for: defining the expected shape of the data up front, so structural problems get caught before they turn into a runtime error somewhere downstream.