PDFFlare
9 min read

How to Validate JSON Against a Schema (Generate + Validate Guide)

You ship the integration, run your tests, deploy. Three days later someone files a bug because a third-party API started returning amountas a string instead of a number, your code did the obvious thing — concatenated “42” with “1” to get “421” instead of 43 — and a customer got billed ten times what they owed. A JSON Schema check at the API boundary would have flagged the type change in milliseconds.

In this guide you'll learn how to validate JSON against a schema online for free using PDFFlare's JSON Schema tool — how to generate a Draft-07 schema from a sample, validate any JSON against it, and read the AJV error pointers when validation fails. 100% browser-based — your schemas and payloads stay private.

What Is JSON Schema?

JSON Schema is a JSON-based vocabulary for describing the shape of other JSON documents. It says things like “this object must have a nameproperty of type string,” or “this array must contain only positive integers.” Validators (like AJV in JavaScript or jsonschema in Python) then compare any JSON against the schema and report violations.

The most-used version is Draft-07. Newer drafts (2019-09, 2020-12) add features like $dynamicRef and unevaluated properties, but Draft-07 covers 95% of practical validation needs and has the widest tool support. PDFFlare emits Draft-07 by default.

Why Validate JSON Against a Schema?

  • Catch bad data at the boundary. Validate every API response, every webhook payload, every config file the moment it hits your code — not five layers deep when something explodes.
  • Self-documenting contracts. A schema is a machine- and human-readable description of what a payload should look like. Reviewers, future-you, and consumers can all read it.
  • Type safety beyond the type system.TypeScript erases at runtime; the validator runs at runtime. They're complementary, not redundant.
  • Better error messages.“Field price at path orders[2].items[0] failed minimum: 0” is dramatically more useful than “NaN somewhere in your code.”
  • Generate UI forms automatically. Tools like react-jsonschema-form turn a schema into a working form. One schema → typed validation + a UI editor.

How to Generate a JSON Schema From a Sample (Step by Step)

The fastest way to get started is to generate a schema from a real example payload, then tighten by hand.

  1. Open PDFFlare's JSON Schema tool — no signup needed.
  2. Make sure the Generate tab is selected at the top of the tool.
  3. Paste a representative JSON sample into the input pane. Use the most-populated example you have — fields present in your sample become required.
  4. Click Generate Schema. The output pane shows a Draft-07 schema with $schema, type, properties, required, and items for arrays.
  5. Tighten by hand: mark fields optional with the required array, narrow strings to enum values, add minimum / maximum for numbers, set additionalProperties: false if you want strict schemas.
  6. Save the schema to your repo as schema.jsonand commit. Now it's the contract.

How to Validate JSON Against a Schema (Step by Step)

PDFFlare's validator uses AJV under the hood. The library is lazy-loaded — it only downloads the ~50KB validator on your first Validate click.

  1. Switch to the Validate tab on PDFFlare's JSON Schema tool.
  2. Paste your JSON Schema into the schema pane (left).
  3. Paste the JSON to validate into the data pane (right).
  4. Click Validate.If everything matches, you see “Valid.” If not, every violation is listed with its path, the failed keyword, and a human-readable message.
  5. Fix and re-validate. Iterate until you see green.

Reading AJV Validation Errors

When validation fails, the tool shows a list of errors. Each one has three parts:

  • Path: a dot-and-bracket pointer to the offending value (e.g. data/users/0/age). Tells you exactly where in the document the violation occurred.
  • Keyword: which schema constraint failed — type, required, enum, minimum, format, etc. Tells you the kind of violation.
  • Message:a human-readable description like “must be string” or “must have required property id.” Quick to scan in a list.

A Complete Worked Example

Suppose you're validating user records. A reasonable schema:

{ "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "required": ["id","email"], "properties": { "id": { "type": "integer", "minimum": 1 }, "email": { "type": "string", "format": "email" }, "age": { "type": "integer", "minimum": 0, "maximum": 150 } }, "additionalProperties": false }

Now you receive this payload: { "id": "42", "email": "alice", "age": -1, "extra": "junk" }. The validator reports four violations:

  • data/id— type: must be integer (it's a string).
  • data/email — format: must match email format (no @).
  • data/age — minimum: must be ≥ 0.
  • data — additionalProperties: must NOT have additional property extra.

Four real bugs caught before the data ever reached your code. That's the value of validation at the boundary.

Common Mistakes Writing JSON Schema

  • Forgetting required. A property listed in properties is optional by default. If it must be present, add it to the required array at the same level.
  • Skipping additionalProperties: false. Without it, payloads with extra unknown fields validate successfully. For strict contracts, set this to false.
  • Confusing format with type. type: "string"says “is a string.” format: "email"says “is a string AND looks like an email.” You need both: type for parse-shape, format for content rules.
  • Using enum for everything. Enum is for closed sets. Open sets (free-text descriptions, names) should stay type: string.
  • Forgetting array constraints. By default, an array can be empty or have any length. Use minItems and maxItemsif there's a real bound.

Common Scenarios

Validating a Webhook Payload

Stripe, GitHub, Slack send you JSON over HTTP. The contract changes occasionally. Validate every incoming payload with a schema generated from the docs — when the contract changes, your validator says so immediately, instead of mysterious bugs later.

Config File Validation

Application config (JSON, YAML converted to JSON via JSON to YAML) often gets edited by hand. Validate at startup with a schema — typos in field names, missing required keys, and wrong types are all caught before the app does anything dangerous with the config.

API Contract Testing

Before a release, hit every critical API endpoint, validate every response against a saved schema. Any failure is either a contract break (rollback) or an intentional change (update the schema). Either way you have a clear signal.

Form Input Validation

Schemas describing form input can drive both server-side validation and frontend libraries like react-jsonschema-form. One source of truth, two consumers — much less drift than hand-writing both sides.

Best Practices

  • Generate from a real sample, then tighten.Don't try to write a schema from scratch — generate, then edit. Tightening is way faster than starting blank.
  • Use additionalProperties: false for strict APIs. Catches typos and unintended additions.
  • Version your schemas. Save as schema-v1.json, schema-v2.json, etc. When you change the schema, you can validate old payloads against the old version.
  • Validate at the boundary, not deep. One validate call when data enters your code is far more useful than ten scattered checks throughout business logic.
  • Use format generously. email, uri, date-time, uuid — all are well-supported. They turn vague type checks into precise content checks.

JSON Schema vs OpenAPI vs TypeScript Types

These three look similar but serve different purposes. Knowing which to reach for matters:

  • JSON Schema: Runtime validator. Use at API boundaries to catch bad data before it enters your code. Output of the validator is a list of violations, not types.
  • OpenAPI:A wrapper around JSON Schema for describing entire HTTP APIs (paths, methods, status codes, request/response shapes). Use when you're publishing or consuming an API that needs full contract documentation. OpenAPI internally uses JSON Schema for the body shapes.
  • TypeScript types: Compile-time only. Erased at runtime. Use to catch bugs in your code, not in incoming data. Pair with JSON Schema for full coverage — types in your code, schema validation at the boundary.

A common pattern: maintain JSON Schema as the source of truth, generate TypeScript types from the schema with a tool like json-schema-to-typescript. One source, two consumers, no drift.

Combining Validators With Other PDFFlare Tools

A schema becomes more powerful when combined with other tools:

  • Schema + JSON Generator: Generate fixtures, validate them against your schema, commit only the ones that pass. Fixtures by construction are schema-compliant.
  • Schema + JSON Diff: When the schema fails on a new payload, diff the failing payload against a known-good payload to see exactly what changed.
  • Schema + Generate-from-sample loop: When the API evolves, regenerate the schema from a fresh sample, diff against the old schema, accept the changes you intended.

Privacy: Your Schemas and Data Stay on Your Device

PDFFlare's JSON Schema tool runs entirely in your browser. AJV is loaded locally, validation runs locally, and your schemas + payloads never upload to any server. Safe for production schemas, internal API contracts, and JSON containing customer data, API keys, or PII.

Performance Considerations

AJV is one of the fastest JSON Schema validators available. Some guidance for high-throughput validation:

  • Compile schemas once. AJV pre-compiles schemas into validation functions. Compile once at startup, reuse for every request — orders of magnitude faster than recompiling per request.
  • Use strict: true in production. Catches schema typos (using requierd instead of required) at compile time rather than letting them silently no-op at runtime.
  • Skip formatvalidation if you don't need it. Format checks (especially email, uri) are slower than type checks. Add ajv.addFormat() only for the formats you actually care about.
  • Validate at the boundary, log violations. Production traffic should accept-or-reject at the boundary, not crash deep in business logic. Log every violation with full error info for triage.

Wrapping Up

A schema-based validator catches the silent corruption bugs that types alone can't. Once you're running every API response and every config through a schema check, the class of “the API changed and broke us silently” bug just disappears. It's a tiny investment for a huge stability win.

Got an API contract or config file that needs a schema? Open PDFFlare's JSON Schema tool, generate from your sample, and you're halfway to a stable, self-documenting integration.

Related Tools

  • JSON to TypeScript — types for compile-time checks (pair with schema for runtime)
  • JSON Formatter — format your schema and data before validating
  • JSON Diff — compare an old payload to a new one when contracts evolve
  • JSON Generator — generate test fixtures that match your schema
Back to all posts