JSON Syntax Validator

1. 1Paste or upload JSONPaste your JSON into the editor, or drag a .json, .jsonc, .json5, .ndjson, .geojson or .webmanifest file onto the drop area. Minified and formatted JSON both work, and nothing is uploaded anywhere.
2. 2Press ValidateEvery syntax error is listed at once with its line, column and byte offset, and a caret marking the exact character. Valid JSON shows its root type, size and structure instead.
3. 3Read the warnings tooDuplicate keys and numbers that lose precision are legal JSON that every parser silently accepts. They are listed as warnings with a JSON Pointer to each one, because they are the faults that survive into production.
4. 4Fix it, or let the tool fix itPress a finding to jump the cursor to it. If the text is JSON5, JSONC or a Python dictionary rather than broken JSON, the tool says so and offers a repaired copy you can apply or download.

Check JSON validity in seconds with precise error location, parser feedback, and structural summaries for quick debugging. Paste or upload JSON and press Validate to get an instant pass or fail. When it is valid you see the root type, its size and a full structure report. When it is not, you see every error at once — each with its line, column, byte offset and a caret under the exact character — plus the warnings that no other validator shows you: duplicate keys, and numbers that quietly change value when they are parsed. Everything runs on your device, so private payloads, tokens and internal schemas never leave it.

• Every error, at once — A parser stops at the first fault. This one resynchronises and keeps going, so a file with forty mistakes takes one pass, not forty.
• The same location everywhere — Line, column, byte offset and a caret, computed from the bytes rather than scraped from a browser message — identical on Chrome, Firefox and Safari.
• The faults that pass everywhere else — Duplicate keys and numbers that lose precision are legal JSON. They are also how data disappears silently, so they are reported as warnings.
• Schema, dialects and repair — Check against a JSON Schema, find out that your file is really JSON5, and take a repaired copy in one press.
• Paste or upload — Paste from the clipboard, drop a file, or browse for one. Clear resets the input and the result together.

The single most useful thing a validator can tell you is where to look, and it is the thing most online validators get least reliably. They report whatever the browser's built-in parser says, and those messages are not the same across browsers.

Measured in the three real engines: Safari's parser reports "JSON Parse error: Expected '}'" with no position, no line and no column at all. Firefox reports a line and a column but no character offset. Only Chrome reports all three. A validator that reads those messages with a pattern therefore works properly on one browser in three, and quietly degrades on the others without telling anyone.

• Line and column — Counted in characters, not bytes, so a line beginning with an accented word does not report a column your editor disagrees with.
• Byte offset — What you need when the file is being handled by a script rather than an editor.
• A caret under the fault — The offending line, with the exact character marked. For a long line the excerpt is trimmed around the fault rather than at the start.
• A JSON Pointer — Where the fault sits in the document's structure — /users/3/email — not just where it sits in the text.

A JSON parser is built to produce a value, so the moment it meets something it cannot use it throws and stops. That is correct behaviour for a parser and unhelpful behaviour for a validator: fix the missing comma on line 12, run it again, discover the unquoted key on line 40, run it again.

This validator is not building a value, so it has nothing to abandon. When it meets a token that fits nowhere it records the fault and resynchronises — treating a missing comma as though it were there, closing a container that met the wrong bracket — and carries on to the end of the file. The result is the whole list in one pass. It stops recording at a thousand findings, which is well past the point where a file is worth fixing by hand rather than regenerating.

• Missing separators — A missing comma or colon is treated as a typo and the scan continues, rather than cascading into an error on every following member.
• Mismatched brackets — A closing bracket that does not match its opener closes the container anyway, so one slip does not turn the rest of the file into noise.
• Unterminated strings — A string with a missing quote stops at the end of its line rather than swallowing the remainder of the document.

JSON permits the same key twice in one object. The specification declines to say what should happen, and the practical answer is that every mainstream parser keeps the last occurrence and discards the first without a word.

So a configuration file with a key set twice is valid, and half of it does nothing. A merged API response with a repeated field is valid, and one of the two values is gone. Because it is legal, this stays a warning here rather than a failure — the verdict has to agree with the parser that will actually consume the file — but it is reported with a JSON Pointer to each occurrence and the offset of the first, so you can see both.

• Exact, not approximate — Keys are compared by their decoded value, so a key written as "a" and the same key written with an escape are correctly recognised as the same key.
• Per object, not per document — The same key in two sibling objects is normal and is not reported. Only a repeat inside one object is.
• At any depth — A duplicate nested twenty levels down is found, with the pointer that leads to it.

JSON puts no limit on the size or precision of a number, and almost every parser reads them into a 64-bit float. Above 9,007,199,254,740,991 an integer can no longer be represented exactly, so it is rounded — silently, with no error and no warning, anywhere in the chain.

This is not a theoretical problem. Snowflake IDs, Twitter-style identifiers, order numbers and ledger amounts all live in that range, and the symptom is a record that cannot be found because its ID came back off by a few hundred. The validator checks every numeric literal that could be affected and reports the exact value alongside the value a parser will produce.

• Large integers — Compared exactly, using arbitrary-precision arithmetic rather than the floating-point value that is itself in question.
• Long decimals — A decimal that cannot be recovered from the double it becomes is reported with the value it will actually round to.
• Overflow and underflow — 1e400 becomes Infinity and 1e-400 becomes zero. Neither is representable in JSON, and neither raises an error anywhere else.
• Cheap when it does not apply — A literal of fifteen digits or fewer cannot lose anything, so it is skipped entirely. Only the ones that could be affected are examined.

A large share of files reported as "invalid JSON" are not broken at all. They are written in a dialect: JSONC, which adds comments and trailing commas, or JSON5, which also allows unquoted keys, single quotes, hexadecimal numbers and NaN. Your editor reads them happily; a strict parser refuses them.

tsconfig.json, .eslintrc and most editor settings files are JSONC. A dictionary copied out of a Python session is close to JSON but uses True, False and None. Rather than calling any of these broken, the validator names what it is looking at, lists which constructs are responsible, and offers a strict-JSON copy.

• Comments — Both line and block comments are recognised — and only outside strings, so a URL containing a double slash is left alone.
• Trailing commas — A comma before a closing bracket or brace, reported at the comma rather than at the bracket.
• Quotes and bare keys — Single-quoted strings, unquoted keys, and the typographic quotes a word processor leaves behind.
• Non-JSON literals — NaN and Infinity, hexadecimal numbers, a leading plus or a leading decimal point, and Python's True, False and None.

Every repair comes from a finding the scanner already located, never from a pattern applied to the whole document. That distinction matters more than it sounds: a regular expression that strips comments also removes the double slash inside "https://example.com", and one that strips trailing commas also removes the comma inside "a, b,". The scanner knows which bytes were inside a string and which were not, so neither mistake is available to it.

The repaired document is then validated again before it is offered, and if it is still not valid it is presented as a partial fix with the remaining faults listed. A button that says "Fixed" and hands back something that does not parse is worse than no button.

• What gets fixed — Comments, trailing commas, single and typographic quotes, unquoted keys, hexadecimal numbers, a leading plus or dot, and Python's True, False and None.
• What is flagged as lossy — NaN and Infinity have no JSON spelling. They become null, and the change is called out rather than made quietly.
• Apply or download — Put the repaired text straight back into the editor, or download it as a .json file.

Syntax is only half the question. "Is this the right shape?" is the other half, and it is what a JSON Schema answers. Paste one into the rail and the document is checked against it as well, with each failure carrying a JSON Pointer to the offending value and the line it sits on.

Draft 2020-12 and draft-07 are both supported, and the draft is read from $schema — or inferred when the schema does not declare one, which most schemas written before 2020 do not. That inference matters: draft-07's array form of items means something different in 2020-12, and reading one as the other produces a confident wrong answer rather than an error.

• The full validation vocabulary — type, enum, const, the numeric bounds, string length and pattern, array and object constraints, required and the dependent keywords.
• Applicators — allOf, anyOf, oneOf, not, if/then/else, prefixItems, contains, propertyNames, and both unevaluatedProperties and unevaluatedItems.
• References — $ref, $defs, definitions, $anchor and $id scoping all resolve inside the schema you provide. A reference to another server is reported by name and never fetched.
• format, as the specification defines it — An annotation by default, exactly as both drafts say — a schema with "format": "email" does not reject a bad address unless you ask it to. There is a switch for people who expected otherwise.

One JSON value per line is how log pipelines, BigQuery exports, bulk API bodies and model training sets are written. Read as a single JSON document, such a file produces exactly one error — trailing content at the start of line two — which is technically correct and completely useless.

NDJSON mode validates each record on its own, so a fault is reported against the record it is in. The mode is offered automatically when a file looks line-delimited, and it is offered rather than applied: a tool that silently reinterprets your input is one you cannot reason about.

• Per-record results — Each fault carries its record number as well as its line and column, and the count of records that passed is reported alongside.
• The trailing newline — Every writer terminates the last record with a newline. That final empty line is not a record, and treating it as one adds a spurious error to almost every correctly written file.
• Windows line endings — A carriage return left on the end of a record would otherwise be a control character inside its last token — one error per line on any file written on Windows.
• Empty records — A blank line in the middle is reported rather than skipped. The format has no spacer, so an empty line means a record was written empty.

A file can be perfectly correct JSON and still fail to parse because of three invisible bytes. A UTF-8 byte-order mark — what PowerShell's Out-File, .NET's StreamWriter and Excel's UTF-8 export all write — sits in front of the opening brace, and a strict parser reports an unexpected token at position 0 for a document that is otherwise flawless.

UTF-16 is worse, because it is what Windows PowerShell writes when no encoding is specified at all. Read as UTF-8 it looks like a NUL byte after every character, and the error points at something nobody can see. Both are detected here and handled, and the encoding that was used is reported so nothing happens behind your back.

• UTF-8, with or without a mark — The mark is recognised, stripped and reported. The document is validated as though it were never there.
• UTF-16, with or without a mark — Detected from the mark, or from where the NUL bytes fall — JSON's structural characters are all ASCII, so the pattern is conclusive rather than a guess.
• Malformed bytes — A byte that is not valid UTF-8 is reported as a warning, not a verdict: a browser replaces it before any parser sees it, so it cannot make a document invalid, but it does mean the file is not in the encoding it claims.
• Not text at all — An image renamed .json is refused with that as the reason, rather than producing a syntax error at position 0 for something that was never JSON.

One pass over the raw bytes, with nothing sent anywhere. A 22 MB document is checked in about 0.2 seconds on a normal laptop — including duplicate keys and number precision — because the scanner never builds the values it is checking.

• Valid — A green verdict with the root type and size, and a structure report: total nodes, maximum depth, counts of objects, arrays and keys, the file size in lines and bytes, and the encoding that was used.
• Invalid — A red verdict with every error listed — line, column, JSON Pointer, a plain description and a caret under the exact character — plus a link to the JSON Formatter.
• Warnings — Duplicate keys, numbers that lose precision, unpaired surrogate escapes and unusually deep nesting, each with its location. These do not change the verdict, because a parser will accept them.
• A dialect, when there is one — If the text is valid JSON5, JSONC or a Python dictionary, that is said in as many words, with the option to convert it.

Invalid JSON breaks APIs, configuration and data pipelines, and it usually breaks them somewhere far from where the mistake is. Checking before you send or save catches typos, missing commas, trailing commas and unescaped characters while you still have the file in front of you. The warnings matter more: a duplicate key or a rounded identifier produces no error anywhere, so it survives every test and shows up as missing data weeks later. All checks run locally, so your data stays private.

• Catch errors early — Find syntax problems before they break a deployment or an integration, with the exact line and column rather than a stack trace from a server.
• Catch the silent ones — Duplicate keys and precision loss pass every parser and every existing validator. They are the faults that reach production.
• Check the shape, not just the syntax — A JSON Schema turns "it parses" into "it is what the consumer expects", before the consumer finds out.
• Privacy — Nothing is uploaded. Private API responses, access tokens and internal schemas can be checked without leaving your device.

Everything that decides whether a document is valid is free. Every error rather than the first, duplicate keys, precision warnings, JSON Schema, dialect detection, repair, NDJSON mode and the full structure report are all available on the free plan. Pro adds scale, not features.

• Free — One file at a time, up to 25 MB, plus unlimited pasting. Every check, every warning, schema validation and repair included.
• Pro — Up to 100 files in one pass, sizes limited by your device rather than by us, one ZIP of reports for the whole batch, and machine-readable JSON and CSV reports for a CI step or a ticket.
• Why 25 MB — It is a measurement rather than a round number. A 22 MB document is checked in about 0.2 seconds, so the cap sits where a mid-range phone is still comfortable.

• JSON Formatter
• JSON Minifier
• JSON Viewer
• JSON Diff
• Sort JSON Keys
• Remove JSON Keys