JSON Validator

What is JSON Validation?

JSON validation is the process of checking whether a string is well-formed JSON according to the ECMA-404 and RFC 8259 specifications. A valid JSON document must have correct syntax — properly quoted strings, matched brackets, no trailing commas, and no comments. Beyond syntax, schema validation checks whether the data structure matches a defined shape: required fields exist, values have the right types, numbers are within bounds, and strings match expected patterns.

Developers validate JSON daily — checking API responses, debugging config files, verifying data exports before import, and testing webhook payloads. A syntax error in a JSON config can crash an application at startup, and a missing required field in an API payload silently drops data.

How to Use the JSON Validator

1. Paste your JSON into the input area.
2. Click “Validate” or press Ctrl+Enter.
3. Read the result: valid JSON shows a green confirmation with structure stats (type, depth, key count); invalid JSON shows the exact error with line and column numbers.
4. Optionally expand Settings and paste a JSON Schema to validate structure, types, and constraints beyond syntax.

The validator runs entirely in your browser. Nothing is uploaded, nothing is logged.

Common JSON Syntax Errors

Trailing Commas

JSON does not allow a comma after the last element in an array or object. This is the most common error when pasting data from JavaScript code, where trailing commas are legal:

// Invalid — trailing comma
{"name": "Alice", "age": 30,}

// Valid
{"name": "Alice", "age": 30}

Single Quotes

JSON requires double quotes for all strings. Single quotes are a syntax error:

// Invalid
{'name': 'Alice'}

// Valid
{"name": "Alice"}

Unquoted Keys

Every object key must be a double-quoted string. Bare identifiers are not allowed:

// Invalid
{name: "Alice"}

// Valid
{"name": "Alice"}

Comments

JSON has no comment syntax. Lines starting with // or blocks wrapped in /* */ are syntax errors. If you need comments in configuration files, consider JSONC (JSON with Comments, supported by VS Code and TypeScript) or YAML — but standard JSON parsers will reject them.

Missing Commas

Every element in an array and every key-value pair in an object must be separated by a comma:

// Invalid — missing comma between pairs
{"name": "Alice" "age": 30}

// Valid
{"name": "Alice", "age": 30}

JSON Numbers, Strings, and Escaping

Some documents fail validation for reasons that have nothing to do with brackets or commas — the number and string grammar in JSON is stricter than most people expect.

Number rules. JSON numbers cannot have a leading zero (0123 is invalid — write 123), cannot start with a + sign, and cannot use hexadecimal or octal (0xFF is invalid). NaN, Infinity, and -Infinity are not valid JSON either — they are JavaScript values, not JSON. A decimal point needs digits on both sides, so .5 and 5. are both errors; write 0.5 and 5.0. Watch precision too: integers larger than 2^53 (about 9 quadrillion) lose accuracy once parsed into a JavaScript Number, so large IDs and timestamps should travel as strings.

String escaping. Inside a JSON string, a literal double quote must be escaped as \" and a backslash as \\. Control characters — newline, tab, carriage return — must be written as \n, \t, \r rather than embedded raw, and any character can be written as a \uXXXX escape. The two most common escaping bugs are an unescaped quote that ends the string early (the parser then reports an unexpected token where it expected a comma) and a raw newline pasted in from a multi-line source. If a value holds Windows file paths, regex patterns, or embedded JSON, every backslash inside it must be doubled.

Lowercase literals. null, true, and false are lowercase only. NULL, True, and False are invalid — a frequent slip when hand-converting a Python dictionary, where the equivalents are None, True, and False.

Common JSON Error Messages Decoded

Parsers report the same underlying problems with very different wording. Here is what the most common error messages actually mean and how to fix them:

Unexpected token o in JSON at position 1

This JavaScript error usually means you passed an object to JSON.parse() when it expected a string — JSON.parse(obj) first coerces the object to "[object Object]", and the parser chokes on the leading o. If you already have an object, you don’t need to parse it at all; only parse a raw string received from a network response or a file.

Unexpected end of JSON input

The document was cut off — a truncated API response, an unclosed bracket, or an empty string. Check that every {, [, and " has a matching close. Pasting the JSON here highlights the exact point where the structure ends prematurely.

Expecting property name enclosed in double quotes

Python’s json.loads() raises this when an object key uses single quotes or no quotes, or when a trailing comma leaves the parser expecting another key. Convert every key to a double-quoted string and remove trailing commas.

Expecting ',' delimiter

Two values sit next to each other without a comma between them, or a string contains an unescaped double quote that ends it early. The reported line and column point at the first character the parser could not place.

Extra data

Valid JSON was parsed, but more text follows it — most often a second JSON object on the same line (that is NDJSON, not a single document) or a stray character after the closing brace.

Duplicate Keys, Encoding, and Invisible Characters

Some documents parse without a syntax error yet still cause bugs downstream:

• Duplicate keys. The JSON specification does not forbid repeated keys, but behaviour is undefined — most parsers silently keep the last value, so {"id": 1, "id": 2} collapses to {"id": 2} and data vanishes with no warning. The validator flags duplicate keys so you catch them before they reach production.
• Byte-order marks (BOM). A file saved as “UTF-8 with BOM” begins with an invisible  character. Many strict parsers reject it with an “unexpected token at position 0” error even though the JSON looks perfect on screen. Re-save the file as plain UTF-8, or strip the BOM before parsing.
• Smart quotes and non-breaking spaces. Copying JSON out of a word processor, chat app, or PDF can replace straight quotes (") with curly quotes and normal spaces with non-breaking spaces. They look identical but are not valid JSON delimiters. Retype the quotes or paste through a plain-text editor first.

JSON Schema Validation

JSON Schema lets you define the structure your data must follow. Paste a schema into the Settings panel and the validator checks every constraint:

{
  "type": "object",
  "required": ["name", "email"],
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "email": { "type": "string", "pattern": "^[^@]+@[^@]+$" },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 }
  },
  "additionalProperties": false
}

This schema requires name and email to be present, enforces types and constraints, and rejects any extra fields. The validator reports every violation — not just the first one — so you can fix all issues in one pass.

Supported Schema Keywords

JSON Schema Draft Versions

JSON Schema has evolved through several drafts, and keywords differ between them. Draft-04 used a boolean exclusiveMinimum/exclusiveMaximum and an id keyword. Draft-06 and Draft-07 switched those bounds to numeric values, renamed id to $id, and added const, contains, and the if/then/else conditionals. Draft 2019-09 and 2020-12 moved definitions to $defs and reworked how items handles tuples. This validator targets the widely used Draft-07 keyword set, which covers the overwhelming majority of real-world schemas from OpenAPI definitions, config files, and API contracts. If a keyword from a newer draft appears to be ignored, check which draft your schema declares in its $schema field — mixing keywords from different drafts is a common source of confusion.

JSON Validator vs JSON Schema Validator

This page answers two questions at once: is this valid JSON? — always — and, when you paste a schema into the Settings panel, does the data match that shape? That makes it the fast path when your goal is catching a syntax error or running a quick one-off schema check against a single document.

If schema validation is the whole point — you maintain a schema, validate many payloads against it, want side-by-side schema and document panels, or need per-path output like .age: 130 > maximum 120 — use the dedicated JSON Schema Validator instead. It is built around the schema-first workflow, while this tool is built around the document. To go the other way and produce a schema from example data, start with the JSON Schema Generator.

In short: reach for the JSON Validator to confirm a document is well-formed and error-free; reach for the JSON Schema Validator when the contract the data must satisfy is the thing you are testing.

JSON Validator vs JSONLint

JSONLint is a popular online JSON validator that has been around since 2011. Both tools check JSON syntax, but there are key differences:

If you need syntax-only checking, either tool works. If you need schema validation or care about keeping your data local, this validator does both without sending anything over the network.

Validating API Responses

When debugging REST APIs, paste the response body here to check both syntax and schema compliance. Common scenarios:

• Webhook payloads — verify the payload matches the documented schema before writing handler code.
• Third-party API responses — confirm the structure hasn’t changed after an API version update.
• Mock data — validate test fixtures match the real schema so tests don’t pass on malformed data.
• Database exports — check NDJSON (newline-delimited JSON) line by line, or validate a full JSON array export.

Pair this tool with the JSON Formatter to first beautify a minified response, then validate it against your schema.

Validating Configuration Files

A large share of “invalid JSON” reports come from config files rather than API data. Common cases:

• package.json — npm refuses to install when this file is malformed, and a trailing comma after the last dependency is the classic culprit. Paste it here to find the exact line before running npm install again.
• tsconfig.json and VS Code settings.json — these are really JSONC (JSON with Comments). The editors that own them tolerate // comments and trailing commas, but a strict JSON.parse() in a build script rejects both. If a downstream tool chokes, remove the comments and trailing commas this validator flags.
• .eslintrc.json, composer.json, manifest.json, and GitHub Actions configs — each is read by a parser that expects strict JSON, so validate after hand-editing. A single missing quote can silently disable a workflow or a linter rule.
• Kubernetes and cloud templates — many are authored in YAML but deployed as JSON. Validate the JSON after converting so a conversion artefact never reaches the cluster; the JSON to YAML converter handles the round trip.

Because everything runs locally, you can safely paste config that contains internal hostnames, tokens, or private settings — none of it leaves your browser.

JSON Validation in Code

For programmatic validation in your codebase:

• JavaScript/TypeScript — JSON.parse() for syntax; ajv for schema validation.
• Python — json.loads() for syntax; jsonschema library for schema validation.
• Go — json.Unmarshal() for syntax; gojsonschema for schema validation.
• Java — Jackson or Gson for syntax; everit-org/json-schema for schema validation.

This online tool is for quick, ad-hoc checks. For production pipelines, integrate a schema validator into your CI — ajv-cli for Node.js projects or check-jsonschema for Python-based CI.