You’re mid-feature, your API call returns a 400, and buried in the response is SyntaxError: Unexpected token < in JSON at position 0. Or worse, your background job silently fails because it couldn’t deserialize a payload that looked fine yesterday.
Why is my JSON file invalid? Nine times out of ten, the answer is a single character: a trailing comma, a stray single quote, or a copy-pasted smart quote that isn’t even a real quotation mark. These microscopic mistakes halt entire data pipelines, break webhooks, and crash API integrations.
JSON’s strictness is by design. The format sacrifices flexibility for universal portability — any compliant parser in any language can read a valid JSON document without ambiguity. But that same strictness means the margin for error is zero. One wrong character and the whole document is rejected.
This guide walks through the exact mechanics of how to fix invalid JSON syntax errors — from the most common single-character mistakes to debugging thousand-line minified payloads and handling language-specific parser errors.
The Anatomy of Perfect JSON: Core Syntax Rules
The most reliable way to understand how to fix invalid JSON syntax error reports is to internalize what the parser expects at each level of the document. Before you can fix an error, you need a clear picture of what valid JSON looks like.
JSON (JavaScript Object Notation) was derived as a strict subset of JavaScript object literal syntax, but it has diverged in important ways: JSON has no comments, no trailing commas, no undefined values, and no functions. What remains is a tightly constrained set of six data types:
- Strings — must be enclosed in double quotes:
"hello world" - Numbers — integers or floating point, no quotes:
42,3.14,-7 - Booleans — lowercase only:
trueorfalse - Null — lowercase only:
null - Objects — key/value pairs inside curly braces:
{"key": "value"} - Arrays — ordered lists inside square brackets:
[1, 2, 3]
The double-quote requirement for keys and string values is the most commonly violated rule. Unlike JavaScript, which accepts single-quoted strings and unquoted identifiers, JSON requires every key and every string value to be wrapped in "double quotes".
Proper nesting is equally strict. Every opened { must have a matching }, and every opened [ must have a matching ]. Objects contain key/value pairs separated by colons, with pairs separated by commas — but no comma after the last pair. Arrays contain values separated by commas — but again, no trailing comma after the last element.
A minimal but perfectly valid JSON document looks like this:
{
"name": "Alice",
"age": 30,
"active": true,
"scores": [98, 87, 92],
"address": {
"city": "Berlin",
"zip": "10115"
},
"notes": null
}
Memorize this structure. Any deviation — even a single misplaced character — produces a parse error.
5 Common JSON Errors and How to Fix Them
Understanding the theory is one thing. Most debugging sessions start with a wall of red text and a position number that points somewhere unhelpful. Here are the five mistakes that account for the vast majority of real-world JSON failures, with exact before-and-after examples for each.
1. The Trailing Comma Trap
JavaScript developers run into this constantly. Modern JS engines tolerate — and even encourage — trailing commas in object literals and array definitions. JSON parsers do not.
Every standard-compliant JSON parser treats a comma after the last element as a syntax error. The grammar has no rule for it. This is one of the sharpest points of divergence between JavaScript syntax and JSON syntax.
Invalid JSON:
{
"name": "Bob",
"role": "admin",
}
Valid JSON:
{
"name": "Bob",
"role": "admin"
}
The fix is always removing the final comma. The challenge is finding it. In a large nested document, the offending comma could be ten levels deep. Most text editors with JSON syntax highlighting will flag it immediately — look for a red underline on the closing brace.
Arrays are equally affected:
// Invalid
["apple", "banana", "cherry",]
// Valid
["apple", "banana", "cherry"]
Linters and formatters catch this automatically; building the habit of running them before committing is worth the effort.
2. Difference Between Single Quotes and Double Quotes in JSON
This is arguably the most frequent JSON error for developers coming from Python, PHP, or Ruby — languages where single-quoted strings are idiomatic. Understanding the difference between single quotes and double quotes in JSON is essential: single-quoted strings are simply not valid JSON, full stop.
The JSON specification (RFC 8259) explicitly requires double quotation marks for all strings. Single quotes are not recognized by any spec-compliant parser and produce an immediate syntax error.
Invalid JSON:
{
'username': 'alice',
'token': 'abc123'
}
Valid JSON:
{
"username": "alice",
"token": "abc123"
}
This rule also applies to keys. A JavaScript developer might write {user: "alice"} in source code and expect it to work as JSON. It won’t. Keys must be double-quoted strings: {"user": "alice"}.
If you’re generating JSON programmatically, always use your language’s built-in serialization function (JSON.stringify(), json.dumps(), etc.) rather than building the string manually. Manual concatenation is where single-quote bugs are born.
3. Unescaped Control Characters and Special Quotes
Copy-pasting text from Microsoft Word, Slack, Google Docs, or any rich-text editor introduces invisible characters that break JSON parsers instantly. The most common culprits:
Smart quotes — Word and many mobile keyboards replace straight quotes (") with curly quotes (" and "). These are different Unicode characters (U+201C and U+201D) that no JSON parser will recognize as string delimiters.
Raw newlines inside strings — A string value that spans multiple lines in a text editor may contain literal newline characters. JSON requires these to be escaped as \n within string values, not embedded as actual line breaks.
Tab characters — Tabs inside strings must be escaped as \t.
Invalid JSON (smart quotes and raw newline):
{
"message": "Hello,
world",
"note": "Don’t miss this"
}
Valid JSON:
{
"message": "Hello,\nworld",
"note": "Don't miss this"
}
The fix is to run your JSON through a validator that normalizes encoding, or to search-and-replace curly quotes with straight ones before parsing. Control character issues are particularly hard to spot in a plain text editor because many invisible characters render identically to whitespace.
4. Missing or Mismatched Closing Brackets/Braces
Deeply nested JSON is where human eyes fail. A configuration file with ten nested objects, or an API response with arrays inside objects inside arrays, is nearly impossible to audit bracket-by-bracket manually.
Invalid JSON (missing closing bracket on the roles array):
{
"users": [
{
"id": 1,
"roles": ["admin", "editor"
}
]
}
Valid JSON:
{
"users": [
{
"id": 1,
"roles": ["admin", "editor"]
}
]
}
Parser error messages for this type of mistake are often misleading. The error position reported is where the parser gave up, not where the missing bracket should have been. If you get an error reported at the very end of a document, work backwards — something deeper in the structure is unclosed.
Color-coded bracket matching in VS Code (or any modern IDE) makes this findable in seconds. Place your cursor on any bracket to see its matching pair highlighted immediately.
5. Incorrectly Formatted Null, Boolean, or Numeric Values
JSON is case-sensitive for its literal keywords. True, False, NULL, and Null are not valid — only true, false, and null are recognized by the spec.
A subtler problem arises when values that should be booleans or numbers are accidentally wrapped in quotes.
Invalid (booleans and number as strings):
{
"isActive": "true",
"isAdmin": "False",
"score": "42",
"ratio": "0.95"
}
Valid:
{
"isActive": true,
"isAdmin": false,
"score": 42,
"ratio": 0.95
}
This distinction matters directly in application code. {"isActive": "true"} passes to your code as the string "true", which evaluates as truthy in JavaScript but will fail a strict boolean comparison (=== true returns false). In typed languages like Go or Java, deserializing a string-typed "42" into an integer field throws a type mismatch error at runtime.
The same applies to null. Writing "null" (with quotes) sends the four-character string "null" to the parser, not the absence of a value.
How to Find Syntax Errors in Large JSON Files
Finding an error in a five-line JSON object is trivial. Finding it in a 50,000-character minified API response or a log file that concatenates thousands of JSON blobs is a different problem entirely.
Why IDEs fall short on large single-line files
VS Code and similar editors do an excellent job of highlighting syntax errors in formatted, multi-line JSON. But minified JSON — where the entire document is one continuous line — exposes their limits. The error underline appears on line 1, and the position number (at position 47,831) is useless without a way to jump directly to that character. Editors also slow down or lag when performing bracket-matching on single-line files that are hundreds of kilobytes long. For very large payloads, the syntax highlighter may simply give up and stop parsing.
The limitations of command-line tools
jq is the gold standard for JSON processing in the terminal. Running jq . < payload.json will immediately exit with a parse error if the document is invalid, and it includes a character position. For engineers comfortable in the terminal, this works well for one-off validation. But it requires installation, some syntax knowledge, and it’s not accessible to QA teams, product managers, or non-technical stakeholders who routinely need to inspect API payloads. It also provides no visual context around the error — you get a position number, not a highlighted diff.
The fastest workflow for any file size
Instead of manually scanning thousands of lines of compressed code, the fastest workflow is to use a dedicated web-based utility. You can instantly paste your payload into our free JSON Formatter Tool; it will pinpoint the exact line containing the error, highlight the broken syntax, and pretty-print it for perfect readability — no installation, no command-line flags, and no context-switching out of the browser.
For automated pipelines, pair a CLI validator with your CI pre-commit hook so invalid JSON payloads never reach production in the first place. Many teams run jq empty < output.json as a lightweight sanity check in their build scripts.
Language-Specific JSON Parsing Errors (And How to Handle Them)
JSON parsing errors surface differently depending on which runtime is doing the parsing. Recognizing the error message by name narrows the fix considerably and points you toward the right recovery strategy.
JavaScript / Node.js: SyntaxError: Unexpected token
try {
const data = JSON.parse(responseBody);
} catch (e) {
if (e instanceof SyntaxError) {
console.error("Invalid JSON:", e.message);
// e.message: "Unexpected token < in JSON at position 0"
}
}
Unexpected token < at position 0 almost always means the server returned HTML (a 404 error page or an nginx default page) instead of JSON. Check the raw response body before assuming the JSON is malformed — validate the Content-Type header and log the raw string.
Python: json.decoder.JSONDecodeError
import json
try:
data = json.loads(raw_string)
except json.decoder.JSONDecodeError as e:
print(f"JSON error at line {e.lineno}, col {e.colno}: {e.msg}")
Python’s error includes line number, column number, and the specific reason (Expecting ',' delimiter, Expecting value, Unterminated string starting at, etc.) — significantly more actionable than the JavaScript equivalent. The e.doc attribute gives you the original string, and e.pos gives the exact character index.
PHP: json_last_error()
$data = json_decode($raw_string, true);
if (json_last_error() !== JSON_ERROR_NONE) {
echo json_last_error_msg(); // e.g., "Syntax error"
}
PHP’s json_decode() returns null on failure without throwing an exception by default. Always check json_last_error() immediately after decoding. For PHP 7.3+, pass JSON_THROW_ON_ERROR as a flag to receive a JsonException instead, which integrates cleanly with try/catch error handling patterns.
Best Practices to Prevent Invalid JSON in Production
Reactive debugging is expensive. These two practices eliminate the majority of JSON syntax errors before they ever reach a parser.
Use serialization libraries, never string concatenation
Building JSON strings by concatenating variables is the root cause of most quote, comma, and encoding bugs. Every major language ships a built-in serializer that handles escaping, quoting, and encoding correctly:
- JavaScript:
JSON.stringify(obj) - Python:
json.dumps(obj) - Go:
json.Marshal(v) - PHP:
json_encode($data)
Treat hand-built JSON strings the same way you treat hand-built SQL queries: a maintenance liability and a correctness risk. The two minutes saved by typing '{"key": "' + value + '"}' instead of calling a serializer will cost hours when a value contains a double quote or a newline.
Implement schema validation at API boundaries
JSON Schema lets you define the exact structure, types, and constraints your API expects, then validate payloads automatically before they reach business logic. Libraries like ajv (JavaScript), jsonschema (Python), and opis/json-schema (PHP) integrate cleanly into middleware pipelines. A schema validation failure returns a meaningful 400 error with field-level details — far more debuggable than a runtime type error thrown five stack frames deep in application code.
Conclusion
Invalid JSON almost always traces back to one of five mistakes: a trailing comma, single quotes instead of double quotes, unescaped special characters, a missing bracket, or a mistyped literal keyword. Understanding how JSON’s strict syntax rules work makes each of these recognizable and fixable in seconds once you know what to look for.
For large, minified, or unfamiliar payloads, visual tooling does the hard work faster than any manual scan. Don’t let syntax errors slow down your development cycle. Bookmark our Online JSON Formatter to validate, clean, and debug your API payloads in one click.