Validating JSON with JSON Schema (Ajv drafts) in the browser

JSON Schema is a vocabulary for describing what a JSON document is allowed to look like: required properties, types, formats, nested objects, and array constraints. Where a JSON formatter only answers “is this parseable?”, schema validation answers “does this instance satisfy this contract?”

Online validators often upload both the schema and the payload. API samples and config shapes can include PII or internal field names. Prefer a local check. LocalTools’ JSON Schema validator runs Ajv (with ajv-formats) in the browser under the same local-only model as other tools on the site.

Schema vs instance

Keep the two documents distinct:

Role	What it is	Example
Schema	Rules for shape and values (type, properties, required, items, …)	{ "type": "object", "required": ["id"], "properties": { "id": { "type": "string" } } }
Instance	One concrete JSON value you want to check	{ "id": "usr_42", "name": "Ada" }

Validation succeeds when the instance satisfies every applicable keyword in the schema under the draft you selected. It fails with a list of errors when something does not match—wrong type, missing required key, string that fails a format, and so on.

Well-formed JSON is necessary but not sufficient. An instance can parse cleanly and still violate the schema. Conversely, a broken schema (invalid JSON or keywords Ajv cannot compile) fails before instance checks run.

Drafts: draft-07, 2019-09, and 2020-12

JSON Schema evolved through several dialects. Keywords and dialect IDs differ; validating a 2020-12 schema with a draft-07 engine (or the reverse) produces confusing false failures or compile errors.

Draft label in the tool	Typical $schema hint	Notes
Draft-07	http://json-schema.org/draft-07/schema#	Still very common in OpenAPI-adjacent and older docs
2019-09	https://json-schema.org/draft/2019-09/schema	Intermediate dialect; vocabularies and $defs patterns
2020-12	https://json-schema.org/draft/2020-12/schema	Current mainstream for new schemas

Pick the draft that matches the schema you pasted—usually the value of $schema at the root, or the dialect your team documents for the contract. The LocalTools validator uses Ajv’s draft-07, 2019, and 2020 entry points accordingly. $schema in the document is informational for you; the dropdown is what selects the engine.

If you are unsure, check the producer’s docs (API gateway, codegen, or OpenAPI tooling). Mixing drafts “to see what works” is a poor debugging strategy—fix the dialect first.

What Ajv checks here (and what it does not)

On LocalTools, validation is:

1. JSON.parse on schema and instance text (syntax errors surface before Ajv runs).
2. ajv.compile(schema) for the selected draft.
3. Run the compiled validator on the instance with allErrors: true so you see multiple problems in one pass when possible.
4. ajv-formats for format keywords such as email, uri, uuid, and date-time (subject to Ajv’s format semantics).

Important limits of this browser workflow:

• Remote $ref URLs are not fetched. External references are not loaded from the network. Inline definitions ($defs / definitions) or resolve $refs into a single document before pasting.
• Meta-schema of the schema itself is not the focus of the UI: the goal is “does this instance match this schema,” not a full schema-linter pass.
• Strict mode is off so common real-world schemas compile without Ajv’s strictness rejecting unfamiliar keywords. That is convenient for exploration; it is not a substitute for CI that pins Ajv options to your team’s policy.
• Business rules outside the schema (authorization, rate limits, “this ID exists in the DB”) are never proven by JSON Schema alone.

For shaping TypeScript from a sample instead of a schema, see generating TypeScript types from sample JSON—that path is heuristic; a real schema is the stronger contract when you have one.

Reading Ajv errors

Failed runs expose rows roughly like:

Field	Meaning
instancePath	Where in the instance the failure was found (JSON Pointer-style path; root often /)
schemaPath	Where in the schema the failing keyword lives
keyword	Which rule failed (type, required, format, additionalProperties, …)
message	Short human-readable explanation from Ajv

Start with instancePath + keyword to find the bad field, then use schemaPath if the schema is large or composed with $refs. Fix the instance or the schema intentionally—do not loosen the contract just to silence an error unless the schema was wrong.

You can copy the error list as JSON from the tool for tickets or chat without pasting the full payload.

A practical workflow

1. Format messy blobs with the JSON Formatter so schema and instance are readable before validating.
2. Confirm the draft from $schema or your team’s dialect docs.
3. Paste schema and instance into the JSON Schema validator (or load the sample to learn the UI).
4. Validate. Fix parse errors first, then compile failures, then validation errors.
5. Inline or bundle $refs if you see missing-reference / compile issues caused by remote URLs.
6. Keep secrets local. Prefer this tab over uploading production payloads to a third-party validator. See why local only matters.

What schema validation will not catch

• Invalid JSON syntax — Fix with a formatter or parser messages before treating schema results as meaningful (what is JSON?).
• Wrong draft — Correct keywords under the wrong engine look like mysterious failures.
• Unresolved remote refs — Bundle the schema first.
• Semantic correctness — A string that matches format: "email" can still be undeliverable; a UUID format check is not proof the resource exists.
• Canonical byte identity — Two valid instances can differ in key order or whitespace; compare parsed data or use a stable pretty-print for diffs (minifying JSON safely, text diffs).

Try it locally

Open the JSON Schema validator:

1. Paste a JSON Schema and a JSON instance (or load the sample).
2. Choose Draft-07, 2019-09, or 2020-12 to match your dialect.
3. Click Validate and inspect path / keyword errors (or the valid result).

Ajv and ajv-formats run in your browser; schema and instance text are not uploaded to LocalTools.

Related reading

• JSON Schema validator — validate an instance against a schema with Ajv drafts locally
• What is JSON? — syntax and value types schemas constrain
• JSON Formatter & Validator — pretty-print and parse-check before schema validation
• Generating TypeScript types from sample JSON — when you only have a sample, not a schema
• Minifying JSON safely — compact vs readable JSON without changing structure
• Why “local only” matters for developer tools
• Text diffs: unified view and workflow — compare schema or fixture edits after formatting