JSON Schema Validator / Generator Guide

What is a JSON Schema validator and generator?

A json schema validator checks whether JSON data conforms to a schema. A json schema generator does the inverse: it looks at sample JSON and builds a candidate schema that describes what it observed. These workflows complement each other, but they are not interchangeable.

Validation is contract enforcement. Generation is contract discovery. If you already know the rules, validation helps you enforce them consistently across requests, responses, config files, events, and fixtures. If you only have sample payloads, generation helps you bootstrap the rules so you have something concrete to refine.

Toolzy.dev keeps both tasks local in the browser, which is useful when the JSON contains internal payloads, customer data samples, or pre-release API shapes. That privacy benefit is valuable, but accuracy still depends on understanding what the tool can and cannot infer.

How to use this tool

1. Paste JSON data into the input.
2. Paste a schema to validate against, or switch to schema generation mode.
3. Run validation or generation. This tool uses JSON Schema Draft 2020-12 for both validation and generated starter schemas.
4. Review the output carefully, especially required fields, array item shapes, unions, and string formats.

When generating a schema, use representative data rather than the smallest possible sample. When validating, make sure your downstream validator accepts JSON Schema Draft 2020-12.

Common use cases

• Validating webhook payloads before they reach business logic
• Generating a starter schema from sample API responses or config files
• Checking that test fixtures still match an expected contract in CI
• Producing machine-readable documentation for internal data formats
• Reviewing event payload changes during backend or schema migrations
• Verifying that external JSON integrations match the structure you expect

Validation vs generation: do not treat them as the same guarantee

This distinction is the most important one to get right.

If you validate json against schema, you are asking whether the data satisfies a predefined contract. The validator can produce precise failures like “missing required property id” or “expected integer, got string.”

If you generate json schema from json, you are asking the tool to infer a likely contract from observations. That means the generated schema reflects the sample, not necessarily the entire real-world domain.

For example, if your sample contains:

{ "status": "ok" }

a generator might infer:

{
  "type": "object",
  "properties": {
    "status": { "type": "string" }
  },
  "required": ["status"]
}

That tells you almost nothing about whether status should really be an enum, whether it can be omitted, or whether other payloads also include "error", "pending", or numeric codes. Generation is a drafting aid, not proof.

JSON Schema draft support

This tool uses JSON Schema Draft 2020-12 for validation and generated schemas. That keeps the output explicit and consistent, but it also means downstream tooling should accept that dialect.

Draft-07 remains widely used because many tools and examples still target it. Draft 2019-09 and Draft 2020-12 introduced newer vocabulary organization and additional keywords. If your generated schema is going into Ajv, OpenAPI tooling, code generation, or a platform-specific validator, check that Draft 2020-12 is supported before treating the output as final.

When teams say “the validator is wrong,” the real issue is often mismatched draft support.

Sample-based generation limits: arrays, unions, optionals, formats

These are the main places where a json schema generator needs manual review.

Arrays

If an array contains representative items, generation is usually straightforward. A sample like:

{ "tags": ["api", "json-schema"] }

can sensibly become an array of strings.

But an empty array tells the generator almost nothing. [] cannot reveal whether the real items are strings, numbers, objects, or a union. Any inferred items schema in that case is broad by necessity.

Unions and mixed values

If one field contains multiple shapes across samples, generation may broaden the schema. A field that appears once as 42 and once as "42" may become a union-like type expression using type arrays or a more complex combinator depending on the tool.

That may be accurate, but it may also be a sign your source data is inconsistent. Generated unions should prompt review, not automatic trust.

Optional vs required properties

Optionals can only be inferred from multiple examples. If every sample object includes email, the generator has no basis for marking it optional. If one sample omits it, then the generator can infer that it may not belong in required.

This is why one golden sample is usually not enough for a reliable schema draft.

String formats

A date-like value such as "2026-04-08T12:00:00Z" is still just a string unless the tool chooses to infer format: "date-time". Some generators add format hints. Others stay conservative. Even when a format is inferred, you should verify that your chosen validator enforces or interprets it the way you expect.

Practical validation workflow for real projects

The most reliable pattern is usually:

1. Generate a starter schema from representative JSON samples.
2. Tighten obvious constraints manually: enums, nullable fields, string formats, minimums, and required arrays.
3. Validate several real payload examples against the schema.
4. Adjust the schema where the sample-based draft was too narrow or too broad.
5. Commit the schema as a maintained contract instead of regenerating blindly forever.

This workflow uses generation for speed and validation for confidence. That combination is much more useful than expecting either feature to solve the whole problem alone.

When generation is enough and when it is not

Generation is often enough for:

• quick internal tooling
• exploratory integration work
• temporary fixture validation
• bootstrap documentation

It is usually not enough by itself for:

• public API contracts
• long-lived event schemas
• shared platform validation used by multiple teams
• compliance-sensitive or strongly versioned data models

In those environments, generated schemas should be the first draft, not the final artifact.

Troubleshooting

Why does validation fail even though the JSON parses correctly? — Parsing only checks syntax. Schema validation checks structure and constraints, so the JSON can be valid text but still violate required fields, types, enums, or item definitions.

Why did the generated schema mark too many fields as required? — The generator only saw samples where those fields were always present. Provide more representative samples or remove fields from required manually.

Why is the generated schema vague for arrays? — Empty arrays or inconsistent items do not provide enough signal. Use representative non-empty arrays if you want accurate items definitions.

Why do unions or broad type arrays appear in the output? — Your samples contain mixed value types for the same property, or the generator is preserving ambiguity. Review whether the underlying data contract is actually polymorphic.

Why does draft selection matter? — JSON Schema drafts differ in supported keywords and interpretation details. This tool uses Draft 2020-12, so downstream tooling should accept that dialect.

Is the JSON processed locally? — Yes. Toolzy.dev runs schema validation and generation in the browser, so your JSON and schema stay on your machine.