How to Validate JSON Against a Schema (With AJV, In Your Browser)

JSON Schema is a vocabulary for describing the shape of JSON data: which properties exist, what type each one must be, which ones are required, and what range or pattern their values must fall within. Validation is the act of checking a real document against that description and reporting every place it deviates.

This is different from JSON syntax checking. A JSON Validator confirms a document is well-formed JSON at all - correct brackets, quotes, and commas. A schema validator goes a level deeper and confirms the *content* is correct: the right types, the right required fields, values inside acceptable bounds. You typically want both, in that order.

Most real-world bugs in JSON-driven systems are not syntax errors - they are contract violations. An API returns a string where the frontend expects a number. A config file omits a field the deploy script assumes exists. A form submits an age of 15 to an endpoint that requires 18 or older. None of these break JSON parsing, but all of them break the application.

• Catch bad data before it spreads - reject a malformed request at the boundary instead of debugging a crash three services downstream.
• Document your data contract - a schema is executable documentation that never goes stale the way a comment can.
• Get exact, actionable errors - instead of a generic failure, you learn the precise property and rule that failed.
• Test generated or third-party data - confirm a payload from another team, an LLM, or a public API actually matches what you were promised.

AJV (Another JSON Validator) compiles a JSON Schema into a fast validation function and then runs your data through it, keyword by keyword. For every property, it checks the applicable rules - type, required, enum, pattern, minimum/maximum, minLength/maxLength, and more - and records a violation whenever one fails.

Crucially, AJV does not stop at the first problem. It walks the entire document and collects every violation it finds in one pass, each tagged with an instance path (where in your data the problem is) and the keyword that failed (which rule was broken). That is what makes the JSON Schema Validator useful for real debugging rather than a slow one-error-at-a-time loop.

1. Open the JSON Schema Validator and paste your JSON Schema into the schema panel - or generate a starting draft with the JSON Schema Generator from a sample document.
2. Paste the JSON document you want to check into the data panel.
3. Run the validation. AJV checks every applicable keyword and lists each violation with its instance path.
4. Fix each reported issue in your data (or loosen the rule in the schema if the rule itself was too strict).
5. Re-run validation until the document passes with no errors.

Once a schema is passing reliably, keep it alongside your fixtures or config so you can re-check future data the same way, without rewriting the checks by hand each time.

Here is a minimal schema that requires an age field to be an integer of at least 18, checked against a document that violates that rule:

// schema
{
  "type": "object",
  "properties": {
    "age": { "type": "integer", "minimum": 18 }
  },
  "required": ["age"]
}

// data
{ "age": 15 }

Invalid: /age must be >= 18 (minimum).

Notice the error names the exact instance path (/age) and the exact keyword that failed (minimum). In a document with dozens of properties, that precision is the difference between a two-second fix and a long manual comparison.

• Enforcing a contract on incoming API request bodies before they reach business logic.
• Verifying config files conform to an agreed schema before a deploy runs.
• Checking that data generated by a script, pipeline, or LLM actually matches the structure you specified.
• Catching missing required fields or wrong types during code review of a fixture change.
• Validating user-submitted JSON - webhooks, form payloads, uploaded settings - against documented rules.

Forgetting the required array

Declaring a property under properties does not make it mandatory. If a field must always be present, it also needs to be listed in the schema's required array - otherwise AJV will silently accept documents that omit it entirely.

Types that are too loose

A type: "object" schema with no properties or required will pass almost anything. Schemas are only as useful as the constraints you actually write into them - be specific about types, formats, and bounds rather than leaving fields open-ended.

Confusing syntax errors with schema violations

If your input is not valid JSON at all - a trailing comma, an unquoted key - that is a parsing problem, not a schema violation, and no validator can check content until the syntax is fixed first. Run a JSON Formatter or validator pass first if you are unsure whether the problem is structural or a rule violation.

Ignoring additionalProperties

By default, JSON Schema allows extra properties beyond the ones you declared. If your contract needs to reject unexpected fields - a common requirement for strict API validation - set additionalProperties: false explicitly; it is not the default behavior.

• Start from real data: generate a draft schema with the JSON Schema Generator and then tighten the constraints that matter, rather than writing a schema from scratch.
• Keep schemas in version control next to the code or config they validate, so contract changes are reviewed like any other change.
• Prefer specific constraints (enum, pattern, minimum, maxLength) over bare type checks whenever the domain has real limits.
• Fix every reported violation in one pass - since AJV returns all errors at once, there is no need to re-run after each single fix.
• Validate untrusted or sensitive input locally rather than sending it to a third-party service, especially for payloads containing tokens or personal data.