Common JSON Errors and How to Fix Them
You just copied a JSON payload from an API log and pasted it into your config file. The app crashes. The error message says "Unexpected token" on line 1. The JSON is one giant unformatted line and finding the error feels impossible.
This happens constantly. JSON is the default data interchange format for nearly every web API, configuration system, and logging pipeline. It looks simple, but its strictness catches people off guard. Unlike JavaScript object literals, JSON has no tolerance for trailing commas, single quotes, comments, or unquoted keys. One misplaced character and the entire payload is rejected.
This guide is a reference for the JSON errors you will actually encounter, where they tend to come from, and how to fix each one. If you need to fix broken JSON right now, paste it into the JSON Formatter and hit Fix Errors.
JSON Syntax Errors Reference
The table below covers the most common JSON syntax errors. Each row shows the error, a minimal example of what triggers it, the fix, and the real-world context where you are most likely to encounter it.
| Error | Example | Fix | Where You'll See It |
|---|---|---|---|
| Trailing comma after last element | {"a": 1, "b": 2,} |
Remove the comma before } or ] |
Hand-edited config files, package.json after reordering dependencies |
| Single quotes instead of double quotes | {'name': 'val'} |
Replace all ' with " around keys and string values |
Python repr() output, JavaScript console logs, quick manual edits |
| Unquoted keys | {name: "val"} |
Wrap every key in double quotes: "name" |
JavaScript object literals copied directly, MongoDB shell output |
| Missing comma between elements | {"a": 1 "b": 2} |
Add a comma after each value except the last: "a": 1, "b": 2 |
Manual JSON construction, merging two payloads by hand |
| Unclosed string (missing closing quote) | {"name": "hello} |
Add the missing closing " to the string value |
Truncated log output, copy-paste errors in config files |
| Unescaped special characters in strings | {"path": "C:\new"} |
Escape backslashes: "C:\\new". Use \\n for literal backslash-n, \\t for backslash-t |
Windows file paths, strings containing tab or newline literals |
| Comments in JSON | {"a": 1} // note |
Remove all // and /* */ comments. JSON does not support them |
Configs copied from JSONC files (VS Code settings, tsconfig.json) |
| Undefined, NaN, or Infinity values | {"val": undefined} |
Use null for missing values. NaN and Infinity have no JSON representation; convert to strings or remove |
JSON.stringify() with special floats, serialized JavaScript objects |
| Duplicate keys | {"a": 1, "a": 2} |
Remove or rename the duplicate. Parsers typically keep the last value, but behavior varies | Merged config files, auto-generated payloads from multiple sources |
| BOM character at start of file | \uFEFF{"a": 1} (invisible bytes before the opening brace) |
Remove the BOM. Save the file as UTF-8 without BOM | Files created or edited in Windows Notepad, Excel CSV-to-JSON exports |
| Newlines inside strings | {"msg": "line one (literal newline in the string) |
Replace literal newlines with \n escape sequence |
Multi-line log messages serialized into JSON, template-generated payloads |
| Hexadecimal numbers | {"color": 0xFF} |
Convert to decimal: 255. JSON only supports decimal number literals |
Config files ported from JavaScript or YAML, color values |
| Leading zeros on numbers | {"code": 007} |
Remove leading zeros: 7. For decimals less than one, use 0.07 |
Zip codes and country codes stored as numbers, legacy data exports |
| Missing colon between key and value | {"name" "val"} |
Add the colon: "name": "val" |
Typos in hand-written JSON, missing separator after copy-paste |
| Empty key name | {"": "val"} |
Technically valid JSON, but usually a mistake. Give the key a meaningful name | Serialization bugs, form-to-JSON converters with missing field names |
| Missing closing bracket or brace | {"items": [1, 2, 3} |
Ensure every { has a matching } and every [ has a matching ] |
Truncated API responses, streaming endpoints that disconnect early |
Most of these errors produce a generic "Unexpected token" or "JSON.parse error" message in your console or application log. The actual error text varies by parser (V8, Python's json module, Go's encoding/json, jq), but the underlying cause is almost always one of the issues listed above.
JSON in the Wild
JSON appears in more places than most developers realize, and each context introduces its own category of problems. Understanding where malformed JSON comes from helps you fix it faster.
API responses. The most common source of broken JSON is an API that returns an error page (HTML) instead of a JSON response, or an API that truncates its output when the payload exceeds a size limit. If your parser throws an error on the first character, check whether the response body is actually JSON at all. A 502 gateway error page is not JSON, even if you expected it to be. When converting API response data to other formats, a CSV-to-JSON converter or a JSON-to-TypeScript generator can save significant manual effort.
package.json and config files. Package managers are strict JSON parsers. A trailing comma in package.json after adding a dependency will cause npm install to fail with an unhelpful error. The same applies to composer.json, .eslintrc.json, and any other tool that expects strict JSON. Note that tsconfig.json and VS Code's settings.json actually use JSONC (JSON with Comments), which is a superset. Copying from those files into strict-JSON contexts will break.
CI configuration files. GitHub Actions workflow files are YAML, but they frequently contain embedded JSON in strategy.matrix values, environment variables, and fromJson() expressions. A malformed JSON string inside a YAML file produces confusing errors because the YAML parser succeeds but the JSON parse inside the workflow fails at runtime.
Log aggregators. Structured logging systems (ELK, Datadog, Splunk) store log entries as JSON. When you export or copy a log line from these tools, the JSON may be escaped twice (stringified JSON inside a JSON string) or may include non-JSON metadata prepended by the logging framework. Pasting this directly into a parser fails. You often need to unescape it first.
Webhook payloads. Services like Stripe, GitHub, and Twilio send JSON payloads to your endpoints. When debugging webhook issues, you typically grab the raw payload from a request inspector or log. These payloads are usually valid, but the way they are logged or displayed may introduce encoding issues, especially if the logging system escapes double quotes or wraps the payload in additional string delimiters.
Browser localStorage. Data stored in localStorage via JSON.stringify() is generally valid, but manual edits through browser DevTools can introduce errors. A common mistake is editing a stored JSON string directly in the Application panel without maintaining proper escaping. If your web application reads from localStorage and throws a parse error on page load, check the stored value in DevTools.
When to Format vs. Validate vs. Minify
These three operations solve different problems, and choosing the wrong one wastes time.
Format (prettify) adds indentation and line breaks to make JSON readable. Use this when you need to inspect a payload visually, find a specific key, or understand the structure of a response. Formatting does not change the data. It is a display-only operation. This is what you want when you pull a one-line JSON blob from an API log and need to make sense of it.
Validate checks whether a string is legal JSON according to the spec (RFC 8259). Use this when you need to confirm that a payload will parse without errors before sending it to another system. Validation tells you whether the JSON is structurally correct. It does not tell you whether the data makes sense for your application. A payload can be valid JSON and still have wrong field names or missing required values.
Minify removes all unnecessary whitespace to reduce payload size. Use this when you are storing JSON in a database, sending it over a network, or embedding it in a URL query string. Minified JSON parses identically to formatted JSON, but it uses fewer bytes. For large payloads, the size difference is significant. A 50KB formatted JSON response might compress to 30KB when minified, before gzip.
In many workflows, you will do all three in sequence: validate that the input is legal, format it to inspect and edit, then minify the result before storing or transmitting. The JSON Formatter handles all three operations in one tool.
Working with JSON Across Formats
JSON rarely exists in isolation. Most real workflows involve converting between JSON and other formats. If you are working with API data that needs to go into a spreadsheet, the path is JSON to CSV. Our guide on CSV-to-JSON conversion covers the edge cases around nested objects, arrays, and how different tools handle them.
If you are building a TypeScript application that consumes a JSON API, generating type definitions from a sample response eliminates an entire class of bugs. The JSON-to-TypeScript guide walks through the process and the tradeoffs between manual and automated type generation.
For authentication workflows, JSON is the payload format inside JWTs. When debugging token issues, a JWT decoder lets you inspect the header and payload claims without writing code. The JSON inside a JWT follows the same syntax rules covered in this article, so the same errors (and fixes) apply to malformed token payloads.
Open the JSON Formatter to fix, format, or validate your JSON now.