Common JSON Validation Errors and How to Fix Them

Why JSON errors feel vague in practice

JSON errors often point to the place where parsing finally failed, not necessarily the place where you made the original mistake. That is why a message like Unexpected token can be triggered by a trailing comma, a missing quote, a pasted comment, or an invalid value several characters earlier.

The fastest workflow is usually: format the payload, fix the first syntax issue, validate again, and only then move on to schema-level problems such as missing required fields or wrong data types.

Quick map of common JSON failures

1) Unexpected token at position X

This is the classic parser error. It usually means the JSON reader found a character that does not belong where it appears. The most common triggers are trailing commas, missing quotes around keys, single quotes instead of double quotes, or values like undefined and NaN that are valid in JavaScript but not in JSON.

{
  name: "Pietro",
  "active": true,
}

In that example, the parser will complain because name is not quoted and the trailing comma aftertrue is also invalid. A formatter is useful here because it makes structural mistakes much easier to spot.

2) Unexpected end of JSON input

This error means the parser reached the end of the payload while still expecting more content. In real systems, this often comes from truncated API responses, copy-paste mistakes, unfinished arrays, or an object that is missing its closing brace.

{
  "user": {
    "id": 42,
    "email": "user@example.com"
  

Start from the bottom of the payload and count unmatched braces and brackets. If the JSON came from a network response, also confirm the upstream service did not abort early or stream partial output.

3) Invalid control character in string

Raw tabs, line breaks, and other control characters are not allowed inside a JSON string unless they are escaped. This commonly appears when someone pastes multiline text directly into a value or when logs are turned into JSON without proper escaping.

{
  "message": "line one
line two"
}

The safe fix is to escape those characters as \n and \t, or serialize the content with a real JSON encoder instead of building the string manually.

4) Number and literal value mistakes

JSON numbers are stricter than many people expect. You cannot use thousand separators like 1,000, incomplete decimals like 1., hexadecimal values, comments, or JavaScript literals such asundefined and Infinity.

5) Valid JSON but failed validation

Parsing and validation are different steps. A payload can be perfectly valid JSON and still fail because your API, schema, or application expects a different structure. This is where errors like “required property missing”, “expected string but got number”, or “additional properties not allowed” usually show up.

{
  "id": "42",
  "email": null
}

If the schema expects id to be numeric and email to be a non-empty string, the JSON is syntactically valid but semantically wrong for that contract. At this point, switch from syntax debugging to schema debugging.

6) Duplicate keys and silent data loss

Some parsers accept duplicate keys and simply keep the last value. That means the payload may technically parse, but you can still lose information or hide an earlier mistake without noticing it right away.

{
  "role": "viewer",
  "role": "admin"
}

A human reading that payload might think both values matter, but most consumers will only keep the last one. If an API request suddenly behaves strangely, duplicated keys are worth checking for, especially in hand-edited fixtures.

7) Hidden encoding and copy-paste problems

Not every JSON failure comes from visible characters. Smart quotes from documents, zero-width spaces from chat apps, or a bad UTF-8 / UTF-16 conversion can all create payloads that look normal in the editor but fail during parsing.

When a payload looks valid but refuses to parse, try pasting it into a formatter that normalizes whitespace, or re-serializing the underlying object from code instead of trusting a copied string.

JSON syntax vs JSON Schema validation

It helps to separate these two layers clearly. Syntax answers the question “is this legal JSON at all?” Schema validation answers “does this legal JSON match the structure the application expects?” Teams lose a lot of time when they mix those stages together.

Debugging API payloads under pressure

In production incidents, JSON debugging is rarely academic. You usually have logs, a failing request, a deadline, and multiple services that may be rewriting the payload. In that situation, keep the loop brutally simple.

1. Capture the raw payload. Do not rely on screenshots or reformatted snippets from chat.
2. Validate the exact body. A later manual edit can hide the original failure.
3. Compare producer vs consumer. Sometimes the sender emits valid JSON, but a proxy, template, or sanitizer breaks it in transit.
4. Check one failing example and one passing example side by side. Diffing real payloads is usually faster than guessing.
5. Fix generation at the source. If the serializer is wrong, patch the producer instead of repeatedly cleaning the output manually.

A reliable workflow for fixing JSON errors fast

1. Format the payload first. Good indentation exposes missing braces, duplicated commas, and malformed nesting immediately.
2. Fix the first reported error only. Later errors are often just downstream noise caused by the earlier syntax break.
3. Separate parsing from validation. First make the JSON syntactically legal, then compare it against the schema or API contract.
4. Check the data source. If the JSON is generated by code, fix the serializer or template rather than editing broken output by hand every time.
5. Re-validate after each change. Small iterations are safer than large rewrites when you are debugging production payloads.

Common causes in real teams

A simple prevention checklist