Free · Fast · Privacy-first

JSON Schema Validator

JSON schema validation checks that your JSON data matches a defined schema document: required fields are present, types are correct, numeric values fall within declared ranges, and strings match expected patterns.

⚡

Validate JSON syntax as a first step

🔒

Clear error messages for invalid JSON

✨

Free and browser-based

⚡

Validate before testing against a schema

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this JSON Validator to your website

Drop the JSON Validator into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/json/json-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/json/json-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

JSON Schema Draft-07 and Draft 2020-12: What Each Validates and Why It Matters

JSON Schema is a vocabulary for annotating and validating JSON documents. It is separate from the JSON syntax specification, RFC 8259, and is published by the JSON Schema organisation as a series of incremental drafts rather than as an IETF standard. Draft-07, released in 2018, is the most widely deployed version in the wild and is the default behaviour in many tools, including older major versions of the AJV library. Draft 2019-09 and Draft 2020-12 introduced breaking changes worth knowing about: $recursiveRef and $dynamicRef replaced some recursive schema patterns, unevaluatedProperties and unevaluatedItems were added for stricter property control, and the definitions keyword was renamed to $defs. When picking a schema validator, confirm which draft it supports against the draft your schemas declare.

Beyond syntax checking, JSON Schema lets you express a rich set of constraints. You can specify the type of each field (string, number, integer, boolean, array, object, or null), put bounds on strings (minLength, maxLength, pattern for regex matching, and named formats like email or date-time), constrain numbers (minimum, maximum, exclusiveMinimum, multipleOf), enforce array rules (minItems, maxItems, uniqueItems, and the schema for individual items), shape objects (required properties, additionalProperties, propertyNames), and apply conditional logic with if/then/else or allOf/anyOf/oneOf composition. A schema validation failure produces structured output that names the exact JSON path, using JSON Pointer notation like /user/address/postcode, where the data deviated from the declared schema.

The practical workflow for any system that exchanges JSON is straightforward. Define a JSON Schema document for each data structure you care about, validate every incoming payload against that schema at the API boundary, and validate outgoing payloads in your test suite. Schema validation libraries exist for every major runtime: AJV for JavaScript and Node.js, jsonschema and python-jsonschema for Python, json-schema-validator for Java, JsonSchema.Net for .NET, jsonschema for Go. Before feeding any data to one of these libraries in development or production, confirm the JSON is syntactically valid first using a tool like FixTools. A schema validator receiving invalid JSON throws a generic parse error rather than a precise schema violation, and that loss of signal makes debugging slower than it needs to be.

Wiring schema validation into a CI pipeline is a high-leverage move that catches contract violations before they reach a deployed environment. A common pattern uses AJV in a small Node.js script that loads every schema in the schemas directory, glob-matches the corresponding example or fixture files in the repository, and runs each one through validate. The script exits with a non-zero status if any pair fails, which fails the pipeline step. For OpenAPI specifications, tools like Spectral and openapi-validator perform schema validation across the entire spec document in one pass and integrate cleanly with GitHub Actions or GitLab CI. The same approach works for runtime middleware: validate the request body against the route schema before the handler runs, and reject any non-conforming request with a 422 that includes the schema error path in JSON Pointer form. Pairing CI-time validation with runtime validation eliminates entire categories of integration bug.

JSON Schema official specification AJV: JSON Schema validator for JavaScript RFC 8259: The JSON Data Interchange Syntax

How to use this tool

💡

Validate your JSON syntax with FixTools before running it through a schema validator.

How It Works

Step-by-step guide to json schema validator:

1
Check JSON syntax first
Paste your JSON into FixTools and validate the raw syntax before doing anything else. Schema validators will either reject malformed input outright or behave unpredictably when handed JSON that does not parse, so confirming syntactic validity up front saves a debugging detour. The check completes in milliseconds for typical document sizes and runs entirely in your browser.
2
Fix any syntax errors
Correct each error reported by the syntax validator at the exact line and column it identifies, then revalidate. JSON parsers stop at the first fatal error, so one fix can sometimes reveal the next one waiting behind it. Continue this cycle until the document passes a clean syntax check with no errors reported anywhere in the input.
3
Proceed to schema validation
With clean parseable JSON in hand, test the document against your JSON Schema using a dedicated schema validator. Popular options include AJV for JavaScript and Node.js, jsonschema for Python, json-schema-validator for Java, and the online sandbox at jsonschema.net. Pick the one that matches your runtime so the validation behaviour mirrors what your application will see in production.

Real-world examples

Common situations where this approach makes a real difference:

Backend API developer

A developer builds a user registration endpoint and writes a JSON Schema for the request body specifying that email is a required string matching an email pattern, age is an integer between 18 and 120, and additionalProperties is false. When a client sends a request that contains usr_name instead of username because of a typo at the integration partner, the schema validator returns a precise error stating that the additional property usr_name is not allowed at the root path. The API returns this as a clean 422 response with the schema error embedded, and the partner debugs their client without involving the API team.

Platform engineer

A platform engineer manages infrastructure-as-code configurations stored as JSON files in a monorepo. They define a JSON Schema for each config type and add schema validation to the CI pipeline using AJV in a Node.js step. A pull request adding a new config file fails CI with a single clear message: /resources/database/maxConnections must be integer, got string. The engineer locates the issue immediately: someone wrote "100" with quotes around it instead of the bare number 100. The schema catches a type error that pure syntax checking would have missed completely.

Mobile app developer

A mobile developer parses API responses to populate a user profile screen and the app occasionally crashes when the avatar field arrives as null instead of the expected string URL. They add JSON Schema validation immediately after the response parse, with the avatar field typed as a union of string or null. The schema validation now confirms the shape of every response before the data reaches the UI layer, the null case is handled explicitly with a placeholder image, and crash reports stop arriving from the field within a release cycle.

Data science team

A data science team ingests JSON event data from multiple upstream sources to train a machine learning model on user behaviour. They define a JSON Schema covering the expected event structure and run every incoming file through a schema validator as part of the data pipeline before features are extracted. Files containing missing required fields, wrong numeric types, or unexpected enum values are quarantined for human review rather than silently entering the training set. This catches upstream regressions early and prevents subtle data quality issues from biasing the model.

Pro tips

Get better results with these expert suggestions:

Always specify the $schema keyword

Including "$schema": "https://json-schema.org/draft/2020-12/schema" (or the matching URL for whichever draft you use) at the top of your schema document tells the validator which draft to apply. Without it, validators may default to different drafts depending on configuration and produce different results for the same input. Explicit schema versioning prevents subtle inconsistencies across environments, libraries, and tooling, and it documents your intent for anyone reading the schema later.

Use additionalProperties: false for strict validation

By default, JSON Schema allows objects to contain properties not listed in the properties keyword, which can hide typos in field names. Setting "additionalProperties": false rejects any property not explicitly declared in the schema, catching misspellings and stray keys at the boundary. In Draft 2020-12, unevaluatedProperties provides even more precise control when you are composing schemas with allOf or anyOf and need to reason about which properties were already covered by a subschema.

Validate syntax before schema testing

Schema validators typically throw an unhelpful parse error when handed syntactically invalid JSON, rather than reporting a schema violation. Run a syntax validation pass first using FixTools or your runtime native parser, fix any issues that surface, and only then run the schema validator. Separating the two failure modes makes each error message more meaningful and prevents the schema team from chasing a problem that actually belongs to the upstream serialiser.

Use JSON Pointer paths in error messages

AJV and most schema validators report errors using JSON Pointer notation defined by RFC 6901: paths like /items/2/price mean the price field in the third element of the items array, counting from zero. Learning this notation makes schema validation error output immediately actionable rather than requiring manual traversal of a deeply nested data structure to locate the offending value. Most schema validator GUIs let you click the pointer to jump straight to the field.

FAQ

Frequently asked questions

JSON syntax validation checks that a string is parseable, correctly-formed JSON according to the RFC 8259 grammar. JSON schema validation goes further and checks that the parsed data matches a declared structure: correct field names, correct data types, required fields all present, numeric values within ranges, string values matching patterns or named formats. You need both checks for production systems. Syntax validation is a prerequisite that confirms the bytes are parseable, and schema validation is the application-level constraint check that confirms the parsed shape is what your code expects to handle.

FixTools focuses on JSON syntax validation against RFC 8259. For schema validation against a custom JSON Schema document, whether draft-07, 2019-09, or 2020-12, use a dedicated schema validator. For interactive in-browser schema validation, jsonschema.net lets you paste both the schema and the data side by side and see violations highlighted. For programmatic use in your codebase, AJV is the de facto choice in Node.js and browsers, jsonschema is the standard in Python, and similar libraries exist for every other major runtime. Run FixTools first, then the schema tool.

Schema validators throw a generic, often confusing parse error when handed input that is not parseable JSON in the first place, rather than reporting a precise schema violation. Separating the two checks means each error message tells you exactly what the problem is. Syntax validation failure means the JSON itself cannot be parsed by any RFC 8259 parser and the upstream producer needs to fix it. Schema validation failure means the JSON parses cleanly but the resulting data does not match the declared structure. Two different problems, two different teams, two different fixes.

Draft 2020-12 is the most recent stable JSON Schema specification, released in 2021. It introduced $dynamicRef and $dynamicAnchor as replacements for the earlier $recursiveRef and $recursiveAnchor from 2019-09, added unevaluatedItems and unevaluatedProperties for more precise validation in composed schemas, and added prefixItems for tuple-style validation of array positions. Support for Draft 2020-12 varies by library: AJV 8.x supports it out of the box, while older versions default to draft-07 unless you opt in. Check your library docs for the supported drafts before choosing one.

Use the items keyword to apply a schema to every element of the array, or prefixItems in Draft 2020-12 if you need positional schemas where each index has its own shape. A typical example: {"type": "array", "items": {"type": "object", "required": ["id", "name"], "properties": {"id": {"type": "integer"}, "name": {"type": "string"}}}}. This validates that every element of the array is an object containing at least an integer id field and a string name field. You can layer additional constraints like minItems or uniqueItems on top.

The additionalProperties keyword controls whether an object is permitted to contain properties that are not declared in the properties keyword. Set to false, it rejects any unexpected property and makes the schema strict, which is the right choice for catching typos in field names and detecting upstream changes. Set to a schema object, it validates any extra properties against that schema. Set to true, which is the default, it allows arbitrary additional properties without any validation. Strict schemas almost always set additionalProperties to false at every object level.

Yes, through the format keyword. JSON Schema defines a set of named format validators including date for YYYY-MM-DD strings, time for HH:MM:SS strings, date-time for full ISO 8601 timestamps, email, uri, uuid, and several others. Whether format validation is actually enforced depends on the validator and its configuration: AJV requires explicit opt-in with strict format mode or by adding the ajv-formats package, since formats are treated as annotations by default. Check your validator documentation to confirm format checking is active before relying on it for inputs.

JSON Schema is not an IETF standard, since no RFC currently defines it, but it is a widely adopted community specification maintained at json-schema.org with the drafts published as Internet-Drafts. Despite the lack of official RFC status, JSON Schema is integrated into OpenAPI 3.x as the schema language for request and response bodies, used by major API gateways and platforms, and supported natively by VS Code, IntelliJ, and most API documentation tools for autocomplete and validation. Its broad adoption across the industry makes it the de facto standard for declarative JSON data validation.

Most schemas written for draft-07 work without modification under Draft 2020-12, but a handful of breaking changes need attention. Rename every definitions block to $defs because the keyword was renamed. Replace any $recursiveRef or $recursiveAnchor usage with the new $dynamicRef and $dynamicAnchor counterparts, which have slightly different semantics around dynamic scope resolution. If your schema relies on the items keyword with an array value for tuple validation, migrate it to prefixItems with a separate items entry for the tail. Update the $schema declaration at the top of the file to the 2020-12 URL so validators select the correct draft. Then run your existing test fixtures through an updated validator like AJV 8 to confirm behaviour is unchanged. The migration usually completes in under an hour for a single schema document.