JSON Schema from a sample — Draft 2020-12 / Draft-07

Schema inference exposes your data model

Generating a JSON Schema requires an input sample. Those samples are often real API responses, database exports, or form submission examples — which means they may contain email addresses, user IDs, permission roles, or transaction figures. The generated schema then makes the data model explicit: additionalProperties: false, format: "email" annotations, and field names together give anyone reading the schema a detailed map of the application’s internals.

A JSON Schema is roughly equivalent in information density to a database schema. Sending it — or the sample it was derived from — to an external service is handing over a structural blueprint of your application.

The risk of submitting sample data to a schema generator

Online JSON Schema generators receive the full input JSON and process it server-side. If the sample contains real user data, it arrives on the server. The generated schema is also a document — its field names and type annotations are a readable description of your data model that the operator can log or analyse.

Development teams often reach for real data when generating schemas precisely because it gives better field coverage. That pragmatic choice becomes a data exposure if the tool used is a server-side service.

JSON.parse and local type inference keep everything in the browser

This tool parses the input with JSON.parse and walks the object tree recursively, inferring each field’s type locally. Format detection (email / uri / uuid / date / date-time / ipv4 / ipv6) uses local regex matching — no external call. The output JSON Schema conforms to the chosen draft ($schema URI is included) and can be downloaded as .json.

Input sample and output schema both live only in page memory. Paste production-sample data, generate the schema, copy the schema out — and nothing is transmitted to a server throughout.

Wiring directly into OpenAPI 3.1 and AJV

The Draft 2020-12 output slots directly into OpenAPI 3.1 components/schemas. The Draft-07 output is immediately usable with ajv.compile(). Add strict: true to generate additionalProperties: false for APIs that should reject unknown fields. Pair this tool with json-to-ts to get both a TypeScript interface and a JSON Schema from the same sample, covering compile-time and runtime validation with a single source. Normalising the input via json-format first reduces noise when iterating on the sample.

What single-sample inference can and cannot determine

Schema inference from a single sample is fundamentally a generalisation problem, and there are limits to how much can be deduced. This tool assigns string / number / integer / boolean / array / object / null from JavaScript literal types, with arrays merged into a type union where elements differ ([1, "x"] becomes { "type": ["integer", "string"] }). The integer vs number split is made by Number.isInteger() — because JSON parsing collapses 1.0 to 1, a sample that happens to contain only integers will produce a schema that rejects future decimals.

format detection works by matching the string value against regexes; this is an annotation, not a strict validator. Full RFC 5322 email validation is intentionally beyond scope — production validation runs through AJV with ajv-formats, which encodes the more elaborate rules. enum is not inferred automatically: values like status: "active" stay as plain string because deducing “this field is an enum” from a single sample is over-reach. Real-world workflows expect users to hand-edit enum, minLength, and pattern after generation.

Draft 2020-12 vs Draft-07 vs OpenAPI 3.0 dialect differences

JSON Schema has evolved through IETF drafts, and the dialects this tool produces are not identical. In Draft-07, items: [A, B] denoted a tuple where position 0 must be A and position 1 must be B. In Draft 2020-12 that meaning moves to prefixItems; items becomes “the type of any element beyond the prefix.” $id / $ref resolution also gained $dynamicRef in 2020-12, which older toolchains do not understand.

OpenAPI 3.0 is anchored to Draft-04/05-era JSON Schema and uses a proprietary nullable: true keyword, plus a boolean form of exclusiveMinimum. OpenAPI 3.1 finally aligns with JSON Schema 2020-12, making the natural type: ["string", "null"] nullable representation legal. Because the nullable mode in this tool follows 2020-12, pasting that output into an OpenAPI 3.0 document requires rewriting it to nullable: true. When targeting AJV, the Draft-07 output runs unmodified on AJV v6 / v7 / v8, while Draft 2020-12 requires ajv/dist/2020 and a more recent AJV release.