What JSON Schema Actually Validates

An API that documents its request body as "a JSON object with these fields" is describing a shape with no real way to check it. JSON Schema makes that description checkable: a JSON document whose only job is defining what another JSON document is allowed to look like, so "the price field must be a positive number" becomes something code can enforce instead of a comment someone eventually stops reading.

A vocabulary that covers most real cases

A schema is built from a small set of keywords that combine:

• type — "string", "number", "integer", "boolean", "object", "array", or "null" (or an array of several, when a field can be more than one type).
• properties + required — for an object, which keys exist and which must be present. A key not listed in required isn't forbidden, just optional.
• enum — the value must be exactly one of a fixed list ("status" is "pending", "shipped", or "delivered", nothing else).
• pattern, minLength/maxLength — a regular expression or length bound for a string.
• minimum/maximum — a numeric range.
• items — the schema every element of an array must satisfy.
• oneOf / anyOf / allOf — a value must match exactly one, at least one, or all of a list of sub-schemas — the mechanism for "this field is either shaped this way or that way."

A schema for { "name": "Ada", "age": 30 } might look like:

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name", "age"]
}

Validating a document against it means walking both trees together and checking every keyword — { "name": "Ada", "age": -1 } passes the type/required checks but fails on minimum, and the error names exactly which field and which rule.

Two different tools for two different moments, not the same one

It's worth being precise about what JSON Schema validation isn't: a runtime check against one specific document, evaluated at the moment that document exists. JSON Schema Generator & Validator does this in both directions — infer a schema from a sample document, or validate a document against a schema you already have — but either way it's telling you about one piece of data.

JSON to TypeScript solves an adjacent but different problem: producing a type or interface definition your editor and compiler understand before any data exists, catching a mismatch (code reading user.naem instead of user.name) at compile time rather than only when that one bad document happens to flow through at runtime. A real system usually wants both — a schema that validates data crossing a service boundary at runtime, and a generated type that keeps the code handling it honest at compile time — and it's worth keeping the two deliberately in sync rather than assuming one implies the other.

A practical note on how a validator is actually built: some libraries compile a schema on the fly into a purpose-built JavaScript function for speed, using new Function(...) under the hood — fast, but it means the validator needs a security policy that allows compiling code at runtime (unsafe-eval), which a strict site may not want to grant for just one feature's form validation. An interpreted validator — one that walks the schema tree directly on every check rather than generating and compiling new code — is slower per validation, but needs nothing more than running ordinary JavaScript, which is the more conservative default if loosening a site-wide security policy for a single feature isn't worth it.

To get from real data to a first-draft schema, pairing this with JSON Formatter to clean up a messy sample first makes the inferred schema more readable before you refine it by hand.