JSON Validator
Check whether a document is well-formed JSON — with the exact line and column on failure — and optionally validate it against a JSON Schema. Every schema violation is reported with its JSON Pointer path. Runs entirely in your browser.
Input
Result
What this tool does
The JSON Validator answers two questions about a document. First: is it syntactically valid JSON at all? It hands your text to the browser's native JSON.parse and, on failure, normalises the engine's error into a 1-based line and column plus a short snippet that marks the exact character where parsing broke. That turns the famously terse "Unexpected token" message into something you can jump to. Second, and optionally: does a valid document also satisfy a JSON Schema you supply? When the schema box is ticked, every constraint violation is listed with its JSON Pointer location, such as /items/2/port, so you know precisely which value is wrong and why.
Both inputs stay on this page. There is no network request, no telemetry, and nothing is written to storage — the same client-side guarantee as every other tool in this collection, which matters when the payload is a credential, an access policy, or a device attestation blob.
When to use it
Reach for the validator when a parser somewhere downstream rejects your JSON and you need the offending character, when you are hand-authoring a config file and want a fast well-formedness check, or when you maintain a contract (an API request body, a webauthn options object, an applet provisioning manifest) expressed as a JSON Schema and want to confirm a sample conforms. If you only want to pretty-print or minify already-valid JSON, use the JSON formatter instead — this page is about correctness, not layout. To assemble a binary blob from structured fields, see the JSON bin builder.
Inputs and outputs
The top textarea is the instance: the JSON you want to check. The lower textarea is an optional JSON Schema; it is only consulted when "Validate against schema" is ticked, and it must itself be valid JSON. The result panel shows one of a few states: a green VALID JSON badge when syntax is well-formed; an INVALID JSON badge with line, column, and a snippet when it is not; SCHEMA PASS when the instance satisfies every supported keyword; or SCHEMA FAIL with one row per violation, each carrying its JSON Pointer path. The Copy button copies a plain-text summary of whatever the result currently shows.
Supported schema keywords
This is a small, self-contained validator covering a practical slice of draft 2020-12 — enough for everyday contracts, not full conformance.
Covered
type, required, properties, items, enum, const, minimum, maximum, minLength, maxLength, pattern, minItems, maxItems, additionalProperties (boolean), anyOf, allOf, oneOf.
$ref
Local JSON Pointer references only: #/definitions/… and #/$defs/…. Sibling keywords next to a $ref are honoured.
Not covered
Honestly out of scope: format assertions, remote / URL $ref, if/then/else, dependentSchemas / dependentRequired, $dynamicRef, and unevaluatedProperties. For those, use a full library such as Ajv.
Common mistakes
- Trailing commas. JSON forbids the comma after the last array element or object member that JavaScript allows. The reported column usually lands on the closing
]or}. - Single quotes or unquoted keys. Strings and property names must use double quotes.
{'a':1}and{a:1}are both invalid JSON. - Confusing "valid JSON" with "valid against my schema". A document can parse cleanly yet still fail the schema. Tick the schema box to check the second question.
- Expecting
formatto be enforced. Keywords this tool does not implement are silently ignored, not failed — so a passing result only means the supported keywords are satisfied. - Putting the schema in the instance box. The schema goes in the lower textarea; the data you are checking goes in the top one.