Unexpected token, trailing commas, unquoted keys — the most common JSON errors explained, with fixes and a free validator.
Most JSON errors come from a handful of mistakes: trailing commas, single quotes, unquoted keys, missing brackets, and stray characters. A validator points to the exact line; here's what each error actually means, and the precise fix for each one.
First: Find the Error Line
Before trying to fix anything by eye, paste the JSON into the JSON formatter & validator — it reports the error and its exact position, so you're fixing the actual problem rather than hunting blind through a large or unfamiliar structure guessing at what might be wrong.
The Most Common JSON Errors, Explained
1. Trailing Comma
{ "a": 1, "b": 2, }
The comma after 2 is invalid — standard JSON strictly disallows a trailing comma after the last item in either an object or an array. This is one of the most common errors precisely because many programming languages (including JavaScript itself) tolerate trailing commas without complaint, so developers used to that leniency often add one out of habit.
Fix: remove the comma immediately after the last key-value pair or array item.
2. Single Quotes Instead of Double
{ 'name': 'Aarav' }
Invalid — JSON requires double quotes for both object keys and string values, with no exception. Single quotes are common and perfectly valid in JavaScript, Python, and many other languages, which is exactly why this mistake shows up so often when someone writes JSON from memory or copies a snippet from code rather than from an actual JSON source.
{ "name": "Aarav" }
Fix: replace every single quote with a double quote, for both keys and string values.
3. Unquoted Keys
{ name: "Aarav" }
Invalid — every key in a JSON object must be wrapped in double quotes, even though this would be perfectly valid syntax in a JavaScript object literal.
{ "name": "Aarav" }
Fix: wrap every key in double quotes, without exception.
4. Missing or Mismatched Bracket or Brace
Every opening { needs a matching closing }, and every opening [ needs a matching closing ]. A single missing one — easy to miss in a long, deeply nested structure — breaks parsing for everything that follows it, which is why the error location a validator reports for this specific mistake can sometimes point further into the document than where the actual mistake occurred; the parser only realizes something's wrong once it runs out of expected closing characters.
Fix: count opening and closing brackets/braces carefully, or let a formatter's indentation make mismatches visually obvious — a properly indented structure makes an unmatched bracket much easier to spot than a dense, single-line block.
5. "Unexpected Token" Errors
This is one of the most common error messages developers actually search for, and it's a catch-all for several underlying causes: a stray character that doesn't belong, a comment (standard JSON doesn't allow // or /* */ comments at all), or an invalid value like NaN or undefined, neither of which is a valid JSON value.
Fix: remove any comments entirely, and replace undefined with null — JSON's actual representation of an explicitly empty value.
6. Wrong Value Types
Numbers should never be wrapped in quotes if they're meant to be parsed as actual numbers — "42" is a string, while 42 is a number, and code expecting a number may behave unexpectedly if it receives a quoted string instead. Booleans must be lowercase true/false — True/False (capitalized, as in Python) are not valid JSON and will trigger a parsing error.
Fix: remove quotes around genuine numeric values, and ensure booleans are written in lowercase exactly as true or false.
7. Duplicate Keys
{ "name": "Aarav", "name": "Priya" }
Technically, most parsers will accept this without throwing an error, silently using the last occurrence of the duplicated key and discarding the earlier one — which can produce confusing, hard-to-debug behavior rather than a clear error message, since nothing actually fails; the data is just quietly wrong.
Fix: check for accidentally duplicated keys manually, since a validator typically won't flag this as an error the way it flags the syntax mistakes above.
8. Encoding Issues
JSON files saved with an unexpected character encoding, or containing invisible characters (like a byte-order mark at the start of the file) copied in from another source, can cause a parser to fail with an error that doesn't obviously point to an encoding problem at all — it might simply report an unexpected token at the very start of the file.
Fix: if a validator reports an error at the very beginning of an otherwise seemingly correct file, check for and strip any invisible leading characters, and confirm the file is saved as UTF-8, the standard encoding JSON parsers expect.
9. Copy-Paste Artifacts From Rich Text Sources
Copying JSON out of a word processor, a chat app, or a PDF frequently introduces invisible problems that aren't obvious from looking at the text: "smart quotes" (curly “ ” instead of straight " ") silently replacing regular double quotes, non-breaking spaces that look like regular spaces but aren't, or other invisible Unicode characters picked up from the source. These produce confusing errors since the JSON can look completely correct when read visually, while still failing to parse.
Fix: if JSON copied from a non-plain-text source fails validation for no visually apparent reason, try retyping the problematic section manually, or paste it into a plain text editor first (stripping rich-text formatting) before pasting it into the validator.
10. Truncated JSON
A response or file that was cut off mid-transmission — a network interruption, a copy-paste that missed the final characters, a log file that got truncated — produces JSON that looks correct for as long as it goes, but simply stops partway through, typically missing one or more closing brackets/braces at the very end.
Fix: check whether the document actually ends with the closing brace or bracket you'd expect for a complete structure; if it doesn't, the source of the JSON — not the JSON syntax itself — is the actual problem, and you'll need to re-fetch or re-copy the complete data.
Why "Unexpected Token" Specifically Confuses Beginners
The phrase "unexpected token" doesn't name the actual problem directly — it's a generic parser message meaning "I encountered something here that doesn't fit the JSON grammar at this point," which could be caused by any of several underlying issues covered above. This is exactly why pinpointing the location the validator reports matters so much: the message alone often isn't specific enough to diagnose the problem, but the location plus a bit of context around it usually makes the actual cause obvious once you know what to look for.
Errors Specific to Generated or Templated JSON
JSON produced by string concatenation or a templating system (rather than a proper serialization function) is especially prone to a specific class of error: a template variable that happens to contain a double quote, comma, or curly brace within its own value, which then breaks the surrounding JSON structure when substituted in. This is a common source of intermittent, hard-to-reproduce errors — the template works fine for most input values and only breaks for the specific ones containing a character that conflicts with JSON's own syntax.
Fix: never build JSON through manual string concatenation or templating if you can avoid it; use your language's proper JSON serialization function instead, which automatically escapes any special characters within string values so they can't break the surrounding structure.
A Systematic Approach to Debugging Invalid JSON
Rather than scanning an entire document hoping to spot the problem, work through it systematically: paste the JSON into a validator and note the exact reported location; look specifically at that spot and the few characters immediately before it (since the actual mistake is often just before where the parser first noticed something was wrong); check it against the specific error patterns above (trailing comma, unquoted key, single quote, mismatched bracket); apply the fix; and re-validate before assuming it's resolved, since a document can have more than one error and fixing the first one often reveals a second one that was previously masked.
Errors When JSON Comes From a Database Export
JSON exported directly from a database — particularly a NoSQL database dumping its documents to a file — can occasionally include database-specific extensions to standard JSON, like special formatting for large numbers, dates, or binary data, that aren't valid in strict JSON and will fail a standard validator even though the export tool considers it correctly formatted. This is a subtler category of error since the exporting tool itself doesn't consider it broken — it's only "invalid" relative to the strict JSON specification a generic validator checks against.
Fix: check your database's documentation for its specific JSON export format and any non-standard extensions it uses, and use a converter specific to that database (rather than a generic JSON validator) if you need strictly standards-compliant JSON as the end result.
How These Errors Show Up Differently Across Contexts
In application logs, a JSON parsing error typically appears as an exception with a message referencing the parser's specific error format, often including a line and column number matching where the parser first noticed a problem.
In browser developer tools, a failed JSON.parse() call in JavaScript throws a SyntaxError with a description like "Unexpected token" plus the position, viewable directly in the console when debugging a web application.
In config files, a JSON syntax error often prevents an entire application or build process from starting at all, sometimes with an error message that doesn't clearly indicate the problem is JSON-specific — worth checking any recently-edited JSON config file first when an application fails to start unexpectedly.
In API integration testing, a malformed response might not immediately throw a parsing error at all if your code doesn't validate strictly, instead producing confusing downstream behavior (a field silently being undefined) that's harder to trace back to malformed JSON than a hard parsing failure would be.
Why Understanding the Error Beats Memorizing the Fix
It's tempting to treat this list as a lookup table — see an error message, find the matching fix, apply it, move on. That works for isolated, one-off fixes, but understanding why each error occurs (JSON's strict quoting rules, its lack of trailing-comma tolerance, its lack of comment support) makes you faster at recognizing new variations of the same underlying mistake, rather than needing to look up every slightly different error message from scratch. The patterns above cover the overwhelming majority of real-world JSON errors precisely because JSON's syntax rules are simple and few — once you internalize them, most "new" errors turn out to be a small variation on one of the categories already covered here.
Why Some Errors Are Silent Rather Than Loud
Not every JSON mistake produces a clear parsing error — duplicate keys, discussed above, are a good example of a silent failure, since most parsers simply keep the last value and move on without complaint. A similarly silent issue: a number too large or too precise for a given language's numeric type can lose precision during parsing without any error being raised at all, since the JSON itself is perfectly valid — the problem only shows up later, as subtly wrong data in your application, which is considerably harder to trace back to its root cause than a loud, immediate parsing error would be. This is worth keeping in mind precisely because it means "my JSON validated successfully" isn't the same guarantee as "my JSON contains exactly the data I intended."
Avoiding These Errors in the First Place
If you're writing or generating JSON by hand regularly, validate incrementally as you go rather than writing a large block and only checking it at the end — catching an error early, right after you introduce it, is far faster than debugging a large finished document with an error buried somewhere inside it. Better still, avoid hand-writing JSON at all where possible: generate it programmatically using your language's built-in JSON serialization (like JSON.stringify() in JavaScript), which produces syntactically correct JSON automatically and eliminates this entire category of manual mistakes. If you're generating structured markup specifically for SEO purposes, our Schema Markup Generator produces correctly formatted JSON-LD automatically, sidestepping these errors entirely for that specific use case.
Frequently Asked Questions
Why am I getting "Unexpected token" in JSON?
Usually a stray character, a comment (which standard JSON doesn't support), a trailing comma, or an invalid value like undefined. Validate the JSON to find the exact location, then check it against the common error patterns above.
Are comments allowed in JSON?
No — standard JSON doesn't support comments in any form, including both // line comments and /* */ block comments. Remove them entirely before validating.
Can JSON keys be unquoted?
No — every key in a JSON object must be wrapped in double quotes, even though this would be valid syntax in a JavaScript object literal or several other programming languages.
How do I fix invalid JSON fast?
Paste it into a validator, go directly to the flagged line and character position, apply the matching fix from the list above, and re-validate to confirm the fix actually resolved the issue.
Does a JSON validator catch duplicate keys?
Usually not — most parsers silently accept duplicate keys, keeping only the last occurrence, without raising an error. This is a mistake worth checking for manually since a validator typically won't flag it.
Why does my JSON error point to a location further along than where the actual mistake is?
This commonly happens with mismatched or missing brackets — the parser doesn't realize something's wrong until it runs out of expected closing characters, so the reported error location can be further into the document than where the actual problem started.
Why does my JSON fail to parse even though it looks correct when I read it?
This is a common sign of a copy-paste artifact — smart quotes, non-breaking spaces, or other invisible characters picked up from a rich-text source like a word processor or chat app. Try retyping the affected section manually or pasting through a plain text editor first.
Why does JSON that was correct yesterday suddenly fail to parse today?
If nobody edited the file directly, suspect an upstream change — an API you depend on may have altered its response format, or an automated process generating the JSON may have introduced a bug. Validate to confirm it's genuinely broken, then check what changed upstream rather than assuming the file itself was manually altered.
Why does JSON exported from my database fail a standard validator?
Some databases export JSON with non-standard extensions (special date, number, or binary formatting) that aren't valid strict JSON, even though the exporting tool itself treats them as correctly formatted. Check your database's specific export documentation rather than assuming a generic validator's complaint means the export itself is broken.
What if my JSON just stops partway through with no error at a specific line?
Check whether the document is missing its final closing brace or bracket — this usually means the JSON was truncated during transmission or copying, and the fix is to re-fetch or re-copy the complete data rather than editing the JSON itself.
What's the best way to avoid JSON errors when writing JSON by hand?
Validate incrementally as you write rather than only checking a large finished block, and where possible, generate JSON programmatically using your language's built-in serialization rather than hand-writing it, which eliminates most of these errors entirely.
Need help with an app or API? Talk to Scult.
