Common errors, debugging tips, and when to pretty-print vs minify
You paste JSON into a tool, hit format, and get a cryptic error: Unexpected token at position 347. Now you are staring at a wall of text trying to find a missing comma. It happens constantly, and it wastes time. This guide covers the most common JSON errors, how to fix them instantly, and when to use pretty-printing versus minification in your workflow.
JSON (JavaScript Object Notation) is a lightweight data interchange format. It is the standard for APIs, configuration files, and data storage across virtually every programming language. Despite being based on JavaScript syntax, JSON is much stricter than JavaScript. That strictness is why JSON breaks so often — developers write what looks correct in JavaScript, but JSON rejects it.
JSON only supports six data types: strings (double-quoted), numbers, booleans (true/false), null, objects (key-value pairs in curly braces), and arrays (ordered lists in square brackets). Everything outside these rules produces a parse error.
The most common cause of broken JSON is copying data from JavaScript code, YAML files, or log output that looks like JSON but violates the spec. A single misplaced character can invalidate the entire document.
Here are the errors we see most frequently in our JSON Formatter, with exact before-and-after examples.
JavaScript allows them. JSON does not.
Broken: {"name": "Alice", "age": 30,}
Fixed: {"name": "Alice", "age": 30}
JSON requires double quotes for all strings and keys.
Broken: {'name': 'Alice'}
Fixed: {"name": "Alice"}
In JavaScript objects, keys do not need quotes. In JSON, they always do.
Broken: {name: "Alice"}
Fixed: {"name": "Alice"}
JSON has no comment syntax at all.
Broken: {"name": "Alice" // user name}
Fixed: {"name": "Alice"}
Every item except the last needs a comma after it.
Broken: {"name": "Alice" "age": 30}
Fixed: {"name": "Alice", "age": 30}
These are JavaScript values, not valid JSON.
Broken: {"value": undefined}
Fixed: {"value": null}
Backslashes, double quotes, and control characters inside strings must be escaped.
Broken: {"path": "C:\new\folder"}
Fixed: {"path": "C:\\new\\folder"}
JSON numbers cannot have leading zeros (except 0 itself or 0.5).
Broken: {"code": 007}
Fixed: {"code": 7}
JSON only supports decimal numbers.
Broken: {"color": 0xFF0000}
Fixed: {"color": 16711680} or {"color": "#FF0000"}
An opening { or [ without a matching close, or vice versa.
Broken: {"users": [{"name": "Alice"}
Fixed: {"users": [{"name": "Alice"}]}
Fix it now: Paste your broken JSON into our JSON Formatter & Validator — it highlights the exact line and character where the error occurs, so you can fix it in seconds.
JSON can be formatted two ways: pretty-printed (with indentation and line breaks) or minified (all whitespace removed). Each serves a distinct purpose.
Use our Minify tool for production-ready output and our JSON Formatter for development-friendly output.
JSON is the default format for most REST APIs and GraphQL endpoints. When API calls fail with parse errors, the issue is usually one of these:
Wrong Content-Type header. If you send JSON but forget Content-Type: application/json, the server may try to parse your body as form data and fail. Always set the header explicitly.
Double-serialized JSON. This happens when JSON is stringified twice — the server receives a string that looks like "{\"name\":\"Alice\"}" instead of {"name":"Alice"}. Check whether your HTTP library is auto-serializing objects and you are also calling JSON.stringify() manually.
Character encoding issues. JSON must be UTF-8. If your system sends JSON in a different encoding (like Latin-1), special characters will corrupt and break parsing. Ensure your responses include charset=utf-8.
Truncated responses. If a large JSON response is cut off mid-stream (due to timeouts or buffer limits), the result is incomplete and unparseable. Check response size limits and timeout settings.
When debugging API issues, copy the raw response body and paste it into a JSON validator. The validator will pinpoint the exact position of the syntax error, which tells you whether the issue is in the data itself or in how it was transmitted.
JSON is not always the best choice. Here is how it compares to the other major data formats:
| Feature | JSON | YAML | XML |
|---|---|---|---|
| Readability | Good | Excellent | Fair |
| Verbosity | Low | Very low | High |
| Comments support | No | Yes | Yes |
| Native data types | 6 types | Many (dates, etc.) | Text only (needs schema) |
| Parsing speed | Fast | Slower | Moderate |
| Browser support | Native (JSON.parse) | Requires library | Native (DOMParser) |
| API usage | Dominant | Rare | Legacy / SOAP |
| Config files | Common | Very common | Less common |
| Multiline strings | No (use \n) | Yes (block scalars) | Yes |
Use JSON for APIs, browser communication, and anywhere you need fast parsing and broad compatibility. Use YAML for configuration files where readability and comments matter (Docker Compose, Kubernetes, CI/CD pipelines). Use XML when you must — SOAP APIs, legacy systems, or document formats that require schemas and namespaces.
JSON is a data format, not executable code — but mishandling it creates security vulnerabilities.
Never use eval() to parse JSON. In older JavaScript code, you might see eval('(' + jsonString + ')'). This executes arbitrary code if the JSON string contains malicious JavaScript. Always use JSON.parse(), which safely parses data without executing code.
JSON injection. If you build JSON strings by concatenating user input without escaping, an attacker can inject additional keys or modify the structure. For example, if a username contains ", "admin": true, "x": ", it could break out of the value and add unauthorized fields. Always use JSON.stringify() or your language's equivalent to build JSON — never string concatenation.
Sensitive data exposure. Before sending JSON to a client, strip any server-side fields that should not be visible — database IDs, internal flags, or user data belonging to other users. A common mistake is serializing an entire database object and sending all fields in the API response.
When working with JSON from untrusted sources, validate the structure and types before processing. If you expect an object with a name string and an age number, verify those fields exist and have the correct types before using them. Schema validation libraries like JSON Schema make this straightforward.
For encoding sensitive data within JSON payloads for APIs, consider Base64 encoding binary content before embedding it as a JSON string value.
{"a": 1, "b": 2,} is invalid JSON because of the comma after 2. Remove the final comma to fix it.// single-line comments, no /* */ block comments. If you need comments, consider using JSONC (JSON with Comments) supported by some editors, or switch to YAML which natively supports comments.← Blog index | JSON Formatter | Minify Tool | Base64 Encoder | All tools