HomeAll 48 Tools
Case ConversionUppercase to LowercaseTitle CaseSentence CasecamelCasesnake_casekebab-case
Text ToolsWord CounterCharacter CounterText CompareRemove Line BreaksSort LinesLorem Ipsum Generator
Developer ToolsBase64 Encode / DecodeJSON FormatterURL Encode / DecodeUUID GeneratorPassword GeneratorSHA Hash Generator
BlogAboutContactFAQsPrivacy Policy
Guide

10 Common JSON Errors and How to Fix Them

·7 min read

JSON has a deliberately tiny specification, which is why it won — and why the errors are so repetitive. Almost every parse failure you will hit is one of the following ten.

1. Trailing commas

{ "name": "Ada", "role": "Engineer", }   ← invalid

By a wide margin the most common error. A comma separates items, so a comma before the closing brace promises an item that never arrives. JavaScript object literals allow this; JSON never does.

Fix: delete the comma after the final item, in both objects and arrays.

2. Single quotes

{ 'name': 'Ada' }   ← invalid

JSON requires double quotes for both keys and string values. Single quotes are valid JavaScript and invalid JSON — a frequent surprise when copying an object literal out of code.

Fix: use double quotes throughout.

3. Unquoted keys

{ name: "Ada" }   ← invalid

Every key must be a quoted string. JavaScript lets you omit quotes on valid identifiers; JSON does not.

4. Comments

{
  // the user's display name
  "name": "Ada"
}   ← invalid

JSON has no comment syntax at all. Neither // nor /* */ is permitted. This was a deliberate design decision — comments were being used to carry parsing directives, which defeated the point of a simple interchange format.

Fix: remove them. If you genuinely need commented configuration, use JSON5, JSONC, or YAML, and strip comments before parsing as JSON.

5. NaN, Infinity, and undefined

{ "value": NaN, "limit": Infinity }   ← invalid

None of these exist in JSON. It supports numbers, strings, booleans, null, objects, and arrays — nothing else.

Fix: use null, or a string like "Infinity" that your application interprets.

6. Unescaped characters inside strings

{ "quote": "She said "hello"" }   ← invalid

A double quote inside a string ends the string early. The same applies to literal newlines and tabs.

Fix: escape them — \" for a quote, \n for a newline, \t for a tab, and \\ for a backslash itself.

7. Single quotes around numbers, or numbers as strings

{ "count": "42" }   ← valid JSON, probably wrong data

This parses fine but frequently is not what you meant. "42" is a string, so "42" + 1 may give you "421". It happens constantly when converting from CSV, where everything starts as text.

Fix: drop the quotes for genuine numbers. Our CSV to JSON converter has a numeric conversion option that handles this — but leave it off for identifiers like postcodes and phone numbers, where converting to a number destroys leading zeros.

8. Leading zeros and plus signs

{ "code": 007, "temp": +5 }   ← invalid

JSON numbers cannot have leading zeros or an explicit plus sign. 0.5 is fine, .5 is not.

Fix: if the leading zero is meaningful, it is an identifier, not a number — quote it as a string.

9. A BOM or stray whitespace at the start

A file saved as "UTF-8 with BOM" begins with an invisible byte order mark, and many parsers reject it with a baffling "Unexpected token" pointing at position 0. You will stare at a file that looks perfect.

Fix: save as UTF-8 without BOM. In VS Code, the encoding is in the status bar at the bottom right.

10. Truncated output

An error at the very end of a large file usually means the JSON was cut off — a response that hit a size limit, a log that rotated mid-write, or a copy-paste that missed the last lines.

Fix: check the final characters actually close every open bracket. Count your braces, or paste it into the JSON formatter, which reports where parsing stopped.

Reading parser error messages

The messages are terse but informative once you know the pattern:

  • "Unexpected token } in JSON at position 47" — almost always a trailing comma just before that position.
  • "Unexpected end of JSON input" — truncated data, or an unclosed bracket.
  • "Unexpected token o in JSON at position 1" — you passed an object where a string was expected. Something already parsed it; you are double-parsing.
  • "Unexpected token < in JSON at position 0" — the server returned HTML, not JSON. Usually an error page. Check the actual response before debugging your parser.

That last one deserves emphasis: if you see < at position 0, your JSON problem is really a networking or authentication problem wearing a disguise.

A faster workflow

Rather than reading a wall of minified JSON, paste it into the JSON formatter. Valid JSON comes back indented and readable; invalid JSON returns the specific parse error and its position. Everything runs in your browser, so it is safe to paste production API responses containing tokens or customer data.

The key sorting option is useful too: sort keys on two API responses, then run them through the diff checker to see exactly what changed between them.

Try the tool

Convert text between 14 case formats instantly — free, no sign-up, and everything stays in your browser. Open the converter →

More guides

How Many Words Is a 5 Minute Speech?A 5 minute speech runs to roughly 650 words. Here is the full table for every common talk length, why the number is lower than people expect, and how to time yours properly.How Many Pages Is 1,000 Words?1,000 words is roughly 2 pages double spaced or 4 single spaced — but font, margins, and spacing move that number a lot. Here is the full table and what actually changes it.Character Limits for Every Social PlatformEvery platform has two limits: the hard cap, and the much shorter point where your text gets cut off with a "more" link. The second one is the one that matters.Title Capitalization: AP vs Chicago vs APAFour style guides, four sets of rules, and one question: does "over" get a capital? Here is what each guide actually says and how to stop arguing about it.Readability Scores Explained (and Their Limits)Readability formulas measure two things: sentence length and syllable count. That makes them genuinely useful and easy to game. Here is how to read the score honestly.How to Write URL Slugs That RankURLs are a small ranking factor but a large usability one. Here are the rules worth following, and the one mistake that genuinely costs you traffic.Encoding vs Encryption vs HashingBase64 is not encryption. Hashing is not encryption. Confusing these three is behind a surprising number of real security incidents — here is the distinction.Regex Cheat Sheet for BeginnersEverything you need to read and write ordinary regular expressions, in one page — plus the greedy matching trap that catches everybody.Strong Passwords: Length Beats ComplexityP@ssw0rd! is not a strong password. A 20-character random string of only lowercase letters is. Here is the maths behind why, and what actually matters.How to Fix Text You Accidentally Typed in All CapsYou wrote three paragraphs before noticing caps lock was on. Do not retype them — here are four ways to fix it in a couple of seconds.camelCase, snake_case, kebab-case: A Naming GuideFive naming conventions, and the rules for which one to reach for. Most of the choice is decided by your language — the rest is decided by what the name is.Title Case vs Sentence Case: Which Should You Use?Title case looks authoritative. Sentence case reads faster. Here is how to decide which one your headings should use — and the rules for getting each one right.