JSON Schema Generator

Infer a draft-aware JSON Schema from sample data while keeping validation assumptions visible.

Sample JSON

Objects, arrays, scalars, and null are accepted. Duplicate member names and precision-changing numbers are stopped before JavaScript parsing can alter them.

How the sample should be interpreted

Schema draft

Output

Required properties

Array samples

Schema title

Add observed examplesAttach leaf examples and one root example without duplicating whole subtrees.Suggest familiar string formatsRecognize conservative email, URI, date, date-time, and UUID shapes.Preserve null in mixed samplesKeep null alongside another observed type when array samples contain both.Allow unobserved object propertiesLeave objects open instead of rejecting names absent from the sample.

Selected output

Generated schema output will appear here.

Inference runs in this browser component. Pasted JSON stays in the page and browser memory unless you copy or otherwise share it yourself.

One sample can reveal observed shape, not business intent. Required fields, allowed ranges, patterns, uniqueness, and closed vocabularies still need human decisions.

A sample can show structure, but it cannot prove the contract

If a sample contains an integer at $.id, a string at $.name, and an array at $.tags, those observations are reasonable starting types. The same sample cannot tell you whether id must be positive, name has a maximum length, tags must be unique, or a missing property is invalid. Generated schema therefore works best as an explicit draft for human refinement rather than an automatic declaration of policy.

Required means presence, not non-nullness

In JSON Schema, required lists property names that must be present in an object. A required property can still accept null when its own schema allows null. Because one object cannot prove which keys are mandatory in every valid instance, the default here does not infer required properties. The two stricter modes are deliberate heuristics you can opt into when the sample is known to represent a complete record.

Arrays become more trustworthy when more than one item is observed

Merge-all mode combines the types and object properties seen across every sampled element. When object items differ, a property is marked required only if the selected required policy marks it required in every observed object. First-item mode is faster for repetitive data but ignores later evidence and is flagged whenever more items were available.

The generator intentionally does not infer minItems from the sample length. Seeing three elements once does not mean every valid array needs at least three elements.

Format detection is a hint, not proof

Strings that conservatively resemble an email address, URI, calendar date, RFC 3339-style date-time, or UUID can receive a format keyword. A string that happens to look like a date may actually be an opaque identifier, so format suggestions should be removed when the domain meaning does not match the observed shape.

Draft 2020-12 separates format annotation from format assertion, and validator behavior can depend on the implementation and vocabulary configuration. The current JSON Schema specification is published at json-schema.org.

additionalProperties controls how closed an object becomes

Leaving additional properties allowed means names absent from the sample can still validate. Turning the option off sets additionalProperties to false on inferred object schemas, which is a much stronger contract. That can be correct for tightly controlled payloads, but it can also reject legitimate future fields when the sample was incomplete.

Draft choice changes the dialect, not the observed data

The selected $schema URI identifies Draft 2020-12, 2019-09, or Draft 7. The generated subset here uses keywords that are valid across those choices, while avoiding draft-specific tuple syntax and other features that cannot be inferred reliably from one example. Draft 2020-12 is the current published JSON Schema version. Its array vocabulary also distinguishes prefixItems from items for tuple-style schemas, a distinction this sample-driven generator does not guess.

JSON parsing itself has two subtle loss points

Duplicate object member names can be collapsed differently by JSON implementations, and JavaScript numbers cannot exactly represent every JSON numeric literal. Before inference, the input is checked for duplicate names, negative zero, non-finite conversion, unsafe integers, and unusually precise decimal literals that would be rounded. RFC 8259 discusses duplicate-name interoperability and the practical limits around numeric precision: RFC 8259.

What still needs to be authored after inference

Production schemas often need minimum and maximum values, string lengths, patterns, enums, const values, conditional rules, dependentRequired, unevaluatedProperties, references, reusable definitions, array cardinality, uniqueness, and domain-specific descriptions. None of those should be invented from a single payload merely to make the generated schema look more complete.