Skip to content
FormatKit

Free online JSON syntax checker

JSON checker that says what is wrong

This JSON checker is free and needs no signup: paste up to 5 MB and it answers one question — does this parse — then names the line, the column and the character if the answer is no. It recognises eleven classes of mistake by sight, from a trailing comma to a Python dictionary pasted as JSON, counts each of them and offers to fix them in place. When the document does parse it stays useful, flagging the things that are legal but travel badly: duplicate keys, integers too large for a 64-bit float, and nesting deeper than other runtimes will accept.

  • 100% free
  • No signup
  • Up to 5 MB
  • 11 mistakes detected
  • Exact line and column

One question: does this parse? Paste and the answer appears as you type.

Nothing checked yet. The verdict, the line number and the reason all appear here.

How to check JSON

Paste, read the reason, decide what to do about it.

  1. Paste the payload

    Drop it in the box, let a plain ⌘V (Ctrl+V elsewhere) drop it in, or open a file of up to 5 MB. The verdict appears as you type — a green Valid JSON with the shape of the document beside it, or a red Not valid JSON with a line and a column.

  2. Read the cause, not the error code

    Instead of “Unexpected token }”, the bar names what went wrong: a trailing comma before the closing brace, a property name in single quotes, a comment JSON has no room for. Under it sits the offending line with a caret pointing at the exact character, cut to a window around the fault so a one-line 2 MB file is still legible.

  3. Take the offered fixes, or don't

    When the mistakes are ones this page recognises it lists them with a count each — “Trailing comma × 3” — and says whether the document parses once they are applied. Nothing is rewritten until you press Apply the fixes, and the result lands back in the box formatted, so you can see precisely what changed.

Technical specifications

What counts as validRFC 8259 and ECMA-404: one value per document, double-quoted strings and names, decimal numbers, and only space, tab, CR and LF between tokens
Error reportLine, column, the cause written as a sentence, and the offending line with a caret under the character — windowed to 70 characters either side so a one-line file stays readable
Mistakes recognised and offered as fixesTrailing commas, single quotes, curly quotes, unquoted property names, // and /* */ comments, NaN, Infinity and undefined, Python's True, False and None, hexadecimal numbers, 2_500-style digit separators, non-breaking and zero-width spaces, an anti-hijacking )]}' prefix, and newline-delimited JSON pasted as one document
Interoperability warnings on valid documentsDuplicate keys, integers above 9,007,199,254,740,991, literals that overflow to Infinity or underflow to zero, unpaired �–� escapes, nesting past 64 levels, and a bare scalar at the top level
Warning addressesJSON Pointer (RFC 6901), so /lines/1/qty names the node and ~0 and ~1 escape a literal tilde or slash in a key
DepthReads 500 levels. For comparison, .NET's System.Text.Json stops at 64 by default and CPython raises RecursionError under 1,000
FidelityNothing is rewritten unless you press the button; number literals, duplicate keys and key order are all reported as written
Limits and price5 MB per document, checked in your browser; free, no signup, no cap on how many documents you check

Frequently asked questions

How do I check whether a string is valid JSON?

Run it through a parser and see whether it completes — which is what this page does the moment you paste. Valid means it satisfies RFC 8259: double-quoted strings and property names, no trailing commas, no comments, numbers in decimal, and exactly one value in the whole document. Anything else is a syntax error with a position, and the position is more useful than the verdict.

Why does the checker report only one syntax error at a time?

Because after the first one, the parser genuinely does not know what your document was supposed to be. A missing closing brace on line 12 makes everything below it ambiguous — the next 400 lines might be the rest of that object or a sibling that lost its comma — so any tool listing “all” syntax errors is guessing, and the second guess is usually wrong. Fixing the first error and looking again is faster than reading a list of invented ones, and applying the offered fixes does exactly that in a loop.

Are comments allowed in JSON?

No, and their absence was a decision rather than an oversight. Douglas Crockford removed comments from the format deliberately after seeing people use them to carry parsing directives, which would have broken interoperability — the thing JSON existed to provide. If a file needs annotation you have three options: a sibling key such as "_comment", a format that allows them (JSON5, JSONC and YAML all do, and .vscode/settings.json is JSONC for that reason), or a build step that strips them, which is what this page will do for you on request.

Is a trailing comma valid in JSON?

No, in any version, which is why it is the single most common failure people paste here. The confusion is fair: JavaScript has allowed trailing commas in array and object literals since ES5 and in function calls since ES2017, so the habit forms in a file where it is legal and follows you into one where it is not. JSON5 permits them too. Plain JSON never has, and every conforming parser rejects the document rather than ignoring the comma.

Is JSON with the same key twice still valid?

Technically yes, and practically no. RFC 8259 says names within an object SHOULD be unique and then warns that software receiving a document with duplicates behaves unpredictably — most implementations keep the last occurrence, some keep the first, and a few reject the document. This checker treats it as a warning rather than an error and shows you the JSON Pointer of every repeat, because a key appearing twice is nearly always a template or a merge emitting a field it has already emitted.

What does “a second document starts here” mean?

It means the paste holds several complete JSON documents rather than one, which almost always means newline-delimited JSON — the format log pipelines, BigQuery and OpenAI streaming responses emit, where each line is its own record and the file as a whole is not a JSON document at all. The fix is to wrap the records in square brackets with commas between them, and this page offers exactly that as one of its repairs once it recognises the shape.

What is the difference between a JSON checker and a JSON Schema validator?

A checker asks whether the text parses; a validator asks whether the parsed value has the shape you agreed on. This page will happily tell you that {"total": "twelve pounds", "qty": -3} is valid JSON, because the syntax is flawless — only a schema knows that total was meant to be a number and qty at least one. Run the checker first, because a document that does not parse cannot be validated against anything; then take it to the JSON Schema validator, which is linked below.

About checking JSON syntax

“Valid JSON” has moved twice, which is why two tools can disagree about the same file. RFC 4627 defined it in 2006 and required the top-level value to be an object or an array. RFC 7159 replaced that in 2014 and made any value a complete JSON text, so 42 and "ok" became documents in their own right. RFC 8259 finalised it in 2017 and added the requirement that anything crossing between systems be encoded as UTF-8. Alongside those sits ECMA-404, which describes the same grammar and deliberately says nothing about semantics, and RFC 7493, the I-JSON profile, which tightens the rules for interchange: no unpaired surrogates, no duplicate names, and no numbers outside what a double can represent. This page checks against RFC 8259 and reports the I-JSON problems as warnings, because a document can satisfy the standard and still break the next system it reaches.

The absent features are the ones that catch people, and they are absent on purpose. Comments were taken out because they were being used to carry parsing directives, which would have made a JSON document mean different things to different readers — the exact failure the format was invented to avoid. Trailing commas were never in, even though JavaScript has allowed them in literals since ES5, so the habit is formed in a place where it is legal and carried into one where it is not. Single quotes, unquoted keys, NaN and hexadecimal numbers are all JavaScript rather than JSON, and True, False and None arrive whenever somebody prints a Python dictionary and pastes the result. Every one of those is a mechanical substitution, which is why this page can offer to make them for you rather than just pointing and tutting.

Passing a syntax check is a low bar, and it is worth being clear about what it does not mean. A document can parse perfectly and still be wrong for its purpose: {"total": "twelve pounds", "qty": -3} is impeccable JSON. Deciding that total must be a number, that qty must be at least one, and that neither may be absent is a different question with a different tool — the JSON Schema validator, which checks a parsed document against an agreed shape and reports every node that does not fit. Syntax first, shape second; this page is the first half, and it is the half that has to pass before the second one can run at all. When the payload is fine and simply unreadable, the prettifier is next door.

What happens to the document you check

The check runs on your own machine: the parser is JavaScript in this tab, so a payload from a production log can be pasted here without it being uploaded, stored or logged anywhere. The repairs work the same way — they rewrite the text in the box in front of you and nothing leaves it.