What JSON Schema is, first: a vocabulary for describing JSON instances after they already parse. {"id":"1"} is valid JSON. A schema that requires id to be a number will reject it. Those are different failures. The JSON Validator answers the first. A schema validator answers the second.
If you only needed to know whether the text is JSON, stop at parse. Schema is for “this object must have these keys and these types.”
A typical object schema names type, properties, required, and sometimes additionalProperties. Arrays get items. Strings can have minLength or pattern. Numbers can have bounds. enum and const lock values. Local $ref can point at a definition in the same document.
Annotation keywords such as title and description do not change validity. Evaluation keywords do. Mixing them in your head is how people think a pretty title made the instance pass.
A generator that walks one fixture will mark every present key required. It cannot see that email is optional tomorrow. It cannot see that status is an enum of three strings. It cannot invent format: email. Integers look like numbers. Empty arrays have no item type.
The JSON Schema Generator is honest about that. Use it to start a file. Then edit. Then check a second payload. That procedure is how to generate and check a JSON Schema. This article’s job is to say why the raw file is not a contract.
JSON Schema has drafts. Draft 07 is widely spoken. Later drafts add keywords. A browser tool that implements a subset should abort on allOf, anyOf, oneOf, patternProperties, tuple items arrays, and remote $ref. Ignoring those keywords and reporting “valid” would be a false pass.
The JSON Schema Validator on this site follows that rule. format is not evaluated. pattern uses the browser regular expression engine. That is not Ajv, and it is not every draft.
A TypeScript interface inferred from one sample is also not a contract. It has the same “present keys are required” problem. OpenAPI wraps schemas for HTTP, but an OpenAPI file is not a JSON Schema document you paste blindly into a generic validator.
Use a schema when multiple producers must agree. Use types when one compiler must agree. Use parse validation when the text might not be JSON at all.
What JSON Schema is: a way to constrain parsed JSON. What it is not: a pretty-printer, a syntax check, or a complete API description inferred from one example. If you generate from a sample, say so, then edit required keys before you enforce the file.
required is a list of names that must be present. It is not a list of names that must be non-empty strings. A key set to "" or 0 can still satisfy required. If empty strings should fail, add minLength yourself. Generators do not add that constraint.
additionalProperties: false closes the object. Without it, unknown keys usually pass. Teams forget the flag, ship a “schema,” and then wonder why a typo field did not fail CI. Closing the object is a decision, not a default of one-sample inference.
A second payload is still the only honest test. The original fixture will almost always pass the schema it produced. That green check is not evidence. What JSON Schema is, in daily work, is the file you edited plus the instance that was not the source sample.
If you only needed field names, extract keys. Schema is heavier than a path list and lighter than a running service. Pick the artifact that matches the question you are actually asking.
No. Valid JSON means JSON.parse succeeded. A valid instance means the value matches the schema.
They appeared in the sample. A generator cannot see optional fields. Remove names from required if production omits them.
No. It evaluates a documented keyword subset and rejects combinators and remote $ref instead of ignoring them.
OpenAPI uses schemas. An OpenAPI document is not something you should paste into a generic schema validator and trust.
