Does valid JSON mean my API will accept it?

It means the payload will parse. Your API may still reject it for schema reasons — missing fields, wrong types, invalid values. Syntax validation is a necessary first gate, not a full contract check.

Why is the error location sometimes slightly off?

Parsers report where they detected the failure, which can be one token after the real mistake. A missing comma is detected at the start of the next key. When in doubt, inspect the characters just before the reported position.

Is a top-level string or number valid JSON?

Yes. Since RFC 7159 (2014), any JSON value is a valid document: "hello", 42, true, and null all validate. Some older systems still expect an object or array at the top level, but that is their restriction, not the standard's.

Are duplicate keys invalid?

The grammar allows them, so validation passes, but behavior is undefined across parsers — JavaScript keeps the last occurrence. Treat duplicate keys as a data bug even though they validate.

Can I validate NDJSON (one JSON object per line) here?

Not directly — NDJSON is a different format where each line is a separate JSON document. Validate individual lines here, or use the NDJSON to JSON converter first.

Yes. Validation runs entirely in your browser; the input never leaves your machine.

JSON Validator | JSON Tools

About JSON Validator

A JSON validator checks whether text is syntactically valid JSON according to RFC 8259 — the exact grammar that JSON.parse in JavaScript, json.loads in Python, and every standards-compliant API parser enforce. If this validator accepts your input, those parsers will too; if it rejects it, you get the failing line and column so you can fix the problem in seconds instead of hunting through the whole document.

Validation runs locally in your browser as you type, with a short debounce so it does not re-parse on every keystroke. Nothing is sent to a server, making it safe for payloads that contain secrets or customer data.

How to use JSON Validator

Paste or type JSON in the input area.
Validation runs automatically as you type.
If valid, you'll see "Valid JSON"; if invalid, the error and location are shown.

Example

Input

{"name":"DevToolKit","tools":["Validator"],"active":true}

Output

Valid JSON

What the validator checks — and what it deliberately does not

Syntactic validation answers one question: does this text conform to the JSON grammar? It verifies balanced braces and brackets, double-quoted keys and strings, correct comma placement, legal number formats, correct literals (true, false, null), and proper string escaping.

It does not check what the data means. A payload can be perfectly valid JSON and still be wrong for your API — a missing required field, a string where a number is expected, an out-of-range value. That is schema validation, a separate layer typically handled with JSON Schema (ajv in the JS ecosystem), OpenAPI request validation, or types like Zod and Pydantic. A good mental model: syntax validation is spellcheck; schema validation is grammar checking against a contract.

How to read the error location

When parsing fails, the validator reports the line and column where the parser gave up. One subtlety worth knowing: the reported position is where the parser detected the problem, which is sometimes one token after the actual mistake. A missing comma between two properties, for example, is reported at the start of the second property's key — the parser only realizes something is wrong when it sees a quote where it expected a comma. If the error position looks innocent, check the characters immediately before it.

The mistakes that cause 90% of invalid JSON

Invalid JSON almost never comes from typing brackets wrong. It comes from pasting values from other languages and formats:

Python dict reprs: {'key': True, 'x': None} — single quotes, True/False/None capitalization. Use json.dumps() in Python instead of printing the dict.
JavaScript object literals: unquoted keys, single quotes, trailing commas, comments.
Smart quotes from Word, Google Docs, or Slack: “like this” instead of "like this". They look identical at a glance and fail to parse.
Concatenated log lines: two JSON objects back to back ({}{}) is not valid JSON — that is NDJSON, which needs different handling.
Truncated payloads: cut off mid-string by a logging pipeline's line-length limit.

Common errors and how to fix them

Unexpected token, at line 1 column 1

Cause: The input starts with something that is not JSON — a BOM character, an HTML error page returned instead of JSON, or the literal string 'undefined'.

Fix: Check what the first character really is. If an API returned HTML (starts with <), the request failed upstream — validate the request, not the JSON.

Expected ',' or '}' after property value

Cause: A missing comma between properties, or an extra value with no key.

Fix: Look at the line above the reported position — the missing comma is usually at the end of it.

Unexpected string / Expected ':' after property name

Cause: Two strings in a row where the parser expected a separator — usually a missing colon or comma.

Fix: Check the property immediately before the reported column for a missing ':' between key and value.

Unterminated string

Cause: A string is missing its closing double quote, or contains an unescaped double quote inside the value.

Fix: Escape inner quotes as \" — e.g. "say \"hi\"". If the JSON was built by string concatenation, switch to a serializer.

Input looks valid but the validator rejects the quotes

Cause: Typographic (curly) quotes pasted from a document editor or chat app.

Fix: Retype the quotes as plain ASCII double quotes, or paste through a plain-text editor first.

Tips and best practices

Validate before you format or convert — every downstream tool assumes parseable input, and the validator gives the most precise error location.
Empty input is not valid JSON, but the literals null, true, 42, and "text" on their own are — RFC 8259 allows any JSON value at the top level, not just objects and arrays.
If you need to validate many payloads in CI, this page is the interactive equivalent of running jq empty file.json or python -m json.tool — same grammar, same verdicts.
Whitespace outside strings never matters: a single-line and a formatted version of the same document are equally valid.

Frequently asked questions

Does valid JSON mean my API will accept it?: It means the payload will parse. Your API may still reject it for schema reasons — missing fields, wrong types, invalid values. Syntax validation is a necessary first gate, not a full contract check.
Why is the error location sometimes slightly off?: Parsers report where they detected the failure, which can be one token after the real mistake. A missing comma is detected at the start of the next key. When in doubt, inspect the characters just before the reported position.
Is a top-level string or number valid JSON?: Yes. Since RFC 7159 (2014), any JSON value is a valid document: "hello", 42, true, and null all validate. Some older systems still expect an object or array at the top level, but that is their restriction, not the standard's.
Are duplicate keys invalid?: The grammar allows them, so validation passes, but behavior is undefined across parsers — JavaScript keeps the last occurrence. Treat duplicate keys as a data bug even though they validate.
Can I validate NDJSON (one JSON object per line) here?: Not directly — NDJSON is a different format where each line is a separate JSON document. Validate individual lines here, or use the NDJSON to JSON converter first.
Is my data private?: Yes. Validation runs entirely in your browser; the input never leaves your machine.

Embed this tool

Add JSON Validator to your own site, blog post, or internal docs — free, no signup. The widget runs entirely in your visitors' browsers, same as it does here.