To generate and check a JSON Schema, infer a draft-07-style document from one sample, edit what the sample cannot know, then validate a different payload against the result. Do not treat the generated file as a closed API contract. Every key that appeared in the sample will look required until you say otherwise.
Use the JSON Schema Generator for the first draft. Use the JSON Schema Validator to check instances against the subset of keywords that page evaluates. Use the JSON Validator first if either the sample or the schema text might not even be JSON.
Paste a real fixture, not an empty object. The generator walks the parsed value and emits type, properties, required, and items. Integers become number because JSON does not distinguish them. Empty arrays have no items. Mixed array items merge types. No enum, format, or combinators are inferred.
That output is a starting point. It describes this sample. It does not prove email will never appear, and it does not prove name is always present in production. For the definition, read what JSON Schema is.
Open the generated schema in an editor. Remove a name from required if real payloads omit it. Add "additionalProperties": false if unknown keys should fail. If extra keys are allowed but must match a type, set additionalProperties to a nested schema. Do not skip this edit. Shipping the raw generated file will reject the next slightly different fixture and look like a flaky test.
If you need enums, formats, or allOf, write them by hand in a full toolchain. The companion validator on this site will abort on those evaluation keywords rather than pretend it checked them.
Keep the sample that produced the schema. Then paste a second instance: a missing optional key, an extra key, a string where a number belongs. Run validate. A green result on only the original sample proves almost nothing. The second payload is the check.
Syntax-valid JSON can still fail the schema. That is the point. A type mismatch, a missing required property, or a disallowed extra key is a schema error, not a parse error.
Sample A:
{"id":1,"name":"Ada","tags":["admin"]}Generate. You should see id, name, and tags required, tags as an array of strings. Suppose production sometimes omits tags and must not accept email. Remove tags from required and set additionalProperties to false.
Sample B {"id":1,"name":"Ada"} should pass. Sample C {"id":"1","name":"Ada"} should fail on id. Sample D {"id":1,"name":"Ada","email":"a@b.c"} should fail as an additional property. If you skipped the edit, B would fail because tags was required in the raw draft.
If you only needed field names, extract keys. If you only needed to know whether the text parsed, validate syntax. If the vendor schema is built from allOf and remote $ref, this site will refuse those keywords. Use a full validator in CI for that file.
Generate and check a JSON Schema is a three-step loop: infer, edit, prove with a second instance. Writing “we generated a schema” without the last two steps is how teams ship a snapshot of one fixture and call it a contract.
Local $ref values that start with #/ can point at a definitions object in the same file. Remote URLs cannot. If you paste a vendor schema that starts with allOf and an HTTP $ref, the on-site validator will stop and name the keyword. That is not a failed instance. It is an unsupported schema. Take that file to CI.
A boolean schema true accepts any instance. false accepts none. Those are legal JSON Schema, and they are easy to leave in a generated file by accident if you were editing by hand. If validate says everything passes and the schema is true, you did not check a contract.
Keep the sample, the edited schema, and the second payload in the same pull request. Reviewers can replay generate and check a JSON Schema without guessing which fixture produced the file. A schema committed alone is an artifact without a test.
If validate names a path such as users[0].age, fix that site in the instance or relax that keyword in the schema. Do not regenerate from sample A to silence an error on sample B. That only hides the drift you were trying to catch.
Every key in the sample was marked required, and extra keys may have been left unspecified. Edit required and additionalProperties, then validate a second instance.
No. The JSON Validator only checks JSON.parse. Schema validation checks the instance against the contract.
The generator does not emit allOf. If you add combinators by hand, the on-site validator will abort rather than evaluate them.
No. It is a JSON Schema object with a draft-07 $schema URI, not an OpenAPI document.
