JSON Validator & Formatter

Check whether a block of JSON is actually valid — and find the exact character where it isn’t

Paste JSON into the left pane and it is parsed as you type. If it conforms, you get a green result plus a structural breakdown: object count, array count, total key count, maximum nesting depth, and byte size. If it does not conform, you get the parser’s message along with the line, column and character offset of the first thing it could not accept — which is nearly always the fastest route to the fix.

All of it runs in your browser. The text is parsed by your own JavaScript engine; nothing is posted to a server, nothing is written to a log, nothing is retained after you close the tab. That matters more for this tool than for most, because the JSON people need to validate in a hurry is usually an API response or a config file, and those routinely contain bearer tokens, connection strings and customer records. If you want a second layer of protection before pasting a payload into a chat message or a ticket, switch on auto-redact, which masks values that look like secrets — more on that below. If your goal is primarily to pretty-print or minify rather than to check conformance, the separate JSON formatter is the better fit.

What "valid" means here

JSON’s grammar is defined by RFC 8259 (and the identical ECMA-404). It is small enough to hold in your head, and validity means conforming to it exactly — not "looks like JSON" and not "my language’s parser accepted it". The permitted values are object, array, string, number, true, false and null, and that is the entire list. Everything people habitually add is a violation:

That last row surprises people who learned JSON on an older parser. Under the original specification the document root had to be an object or an array; RFC 8259 relaxed that, so a bare string, number, true, false or null is a complete, valid JSON document. This validator accepts them.

Reading the error, not guessing at it

The parse error is reported with the raw engine message plus a computed line and column derived from the character offset. Two habits make that far more useful. First, trust the position but look before it: a parser reports where it gave up, which is usually one token past where you went wrong. A missing comma on line 12 is reported at the start of line 13, because line 12 read perfectly well until something appeared that could not follow it. Second, note that the offset is a character index into the raw text, so it stays accurate even in minified single-line JSON where the line number is uselessly always 1.

The most common real-world causes, roughly in order: a missing or extra comma between elements; an unescaped double quote inside a string value; unbalanced brackets after hand-editing; a Windows path such as C:\Users\name pasted into a string without doubling the backslashes; and a truncated response where the network connection dropped mid-body and the closing braces never arrived. That last one has a signature: the error lands at the very end of the input and complains about unexpected end of data.

The two things a parser will not tell you

Validation by parsing answers exactly one question — is this well-formed? Two categories of problem sail straight through, and both cause real production bugs.

Duplicate keys are legal and silently destructive

RFC 8259 says object member names should be unique, but it does not forbid repeats, and it leaves the behaviour for duplicates undefined. So {"role": "user", "role": "admin"} is well-formed JSON. Every JavaScript engine resolves it by keeping the last occurrence, which means this validator reports it as valid and the formatted output shows a single role of admin — the earlier value has vanished without a warning.

Be explicit about the consequence, because it is a genuine limitation of this page: if you need duplicate keys detected, a JSON.parse-based validator cannot do it, and neither can most of the ones you will find. What you can do here is spot the symptom. The statistics panel counts keys by walking the parsed structure, so it reports keys that survived. Compare that count against what you expect the payload to contain, or search the raw input for a key name and count the hits by eye. Different languages disagree on duplicates — some take the first, some take the last, some raise an error — so a document with repeats can genuinely mean different things to your service and to the client calling it.

Correct shape is a separate question from correct syntax

{"user_id": "42", "active": "yes", "created": null} is flawlessly valid JSON and probably a bug: an ID delivered as a string where the consumer expects a number, a boolean expressed as the word "yes", and a required timestamp that is null. No syntax validator can flag any of this, because nothing about it is malformed.

To be clear about scope: this tool does not perform JSON Schema validation. There is no field to supply a schema and no schema keyword support. What it gives you instead is the raw material for checking shape by hand, which for a one-off API payload is usually quicker than writing a schema anyway:

• Tree view renders the parsed document as a collapsible hierarchy with each node’s inferred type, so you can see at a glance that user_id came back as a string rather than a number, or that a field you expected to be an array is an object with numeric keys.
• Max depth tells you how deeply nested the structure is — useful when a consumer has a nesting limit, or when a response is unexpectedly one level deeper than the documentation implies because someone wrapped it in an envelope.
• Object, array and key counts give you a cheap fingerprint. Two responses that should be equivalent but report different key counts differ somewhere, and that is a much faster signal than diffing thousands of lines.
• Byte size is measured on the input as given, which is what you compare against a documented request-body limit.
• Sort keys reorders every object alphabetically at every level. Applied to two payloads from different services, it makes them genuinely diffable, because key ordering is not significant in JSON but line-based diff tools do not know that.

Validating an API payload against what you expected

The usual situation is not an abstract file — it is a response that broke something. A workable sequence:

• Paste the raw response body, exactly as received, before any tooling reformats it. If it fails to parse at all, you have learned something important: the problem is upstream, and you are probably looking at an HTML error page, a truncated body, or a gateway timeout page rather than JSON.
• If it parses, switch to tree view and check the top level. A surprising share of "the API is broken" reports are an envelope mismatch — the client reads data.items and the server started returning items at the root, or the reverse.
• Walk to the specific field that broke. Confirm its type, not just its presence. Numbers arriving as quoted strings is the single most common cross-language integration defect, and it is invisible until you look at the actual value.
• Check for nulls where your consumer assumes a value. A field that is present but null and a field that is absent are different states, and code that only tests for presence will crash on the first.
• Compare the key count and max depth against a known-good response from the same endpoint.

Large numbers, and why an ID can change value

A JSON number has no defined precision limit in the grammar, but JavaScript parses every number into a double-precision float. Integers beyond roughly nine quadrillion — 64-bit database IDs, Twitter-style snowflake identifiers, some financial values — cannot be represented exactly, and the parsed value is silently rounded to the nearest representable one. The document is valid, this validator reports it as valid, and the formatted output will show a number ending in a different digit from the one you pasted. If your identifiers are large integers, this is why the well-known advice is to transmit them as strings.

Auto-redact before you paste a payload into a ticket

Auto-redact masks values that look sensitive before they appear in the formatted output, and shows a count of how many it caught. It works two ways: by key name — anything matching patterns such as password, secret, token, api_key, authorization, client_secret, ssn, cvv and similar — and by value shape, recognising JWTs, bearer tokens, AWS access and secret keys, GitHub, Slack, Stripe and OpenAI key formats, PEM private-key headers, email addresses, credit-card-shaped digit runs and US phone numbers.

Treat it as a helpful net, not a guarantee. It matches known patterns; a secret stored under an unusual key name with no distinctive format will pass through untouched. Always read the redacted output before you share it. The redaction affects only the formatted output pane — your original input is left as typed.

Practical notes

Validation is debounced by a fraction of a second, so a large document does not re-parse on every keystroke, and the work runs as a low-priority update to keep typing responsive. Because parsing is done by the browser, the practical ceiling is your machine’s memory rather than a server-side upload limit — but genuinely large documents will make the tree view sluggish, and for multi-megabyte files a streaming parser in a real language is the right tool.

Two formats that are frequently mistaken for JSON and will not validate here: JSON Lines (also called NDJSON), where each line is an independent document and the file as a whole is not one — validate a single line at a time; and JSON5 or JSONC, the relaxed variants that permit comments, trailing commas and unquoted keys. Config files from tools that accept comments in their JSON are using an extension, not the standard, and a strict validator is correct to reject them.