JSON to JSON Schema Generator

What is JSON Schema?

JSON Schema is a vocabulary for describing JSON. It says "this object must have these keys, of these types, with values matching these patterns" — and then validators (Ajv, jsonschema, opis/json-schema, every OpenAPI tool) enforce that contract. The current standard is Draft 2020-12, which is what OpenAPI 3.1 uses; Draft 7 is the prior version and is still common in older toolchains. The two have minor syntactic differences — this generator emits both.

How to use it

Paste a JSON sample. The output panel emits a corresponding schema with each leaf typed as string, integer, number, boolean, null, plus object / array for containers. With Detect formats enabled, strings matching common patterns get a format hint — email, uri, date, date-time, uuid, ipv4. With Mark required enabled, every key present in the sample is added to required — drop in an array of multiple objects to get an honest required-field list (only keys present in all objects survive). Optional Title and $id fields are added at the top of the schema.

Detected formats

email — anything matching the simple local@host.tld pattern.
uri — strings starting with http:// or https://.
date — YYYY-MM-DD (RFC 3339 full-date).
date-time — YYYY-MM-DDTHH:MM:SS[.fff][Z|+HH:MM] (RFC 3339).
time — HH:MM:SS[.fff][Z|+HH:MM].
uuid — RFC 4122 v1–v5 UUIDs.
ipv4 — dotted-decimal IPv4 addresses.

Other formats from the spec (uri-reference, idn-email, regex, json-pointer) aren't auto-detected; add them by hand if you need them.

Frequently asked questions

Should I trust an inferred schema in production?

Treat it as a starting point. The inferrer can only see what's in your sample — if a field happens to be a positive integer in every example but is documented to allow zero or negatives, the inferred schema is too tight. Likewise, fields that appear in 100% of your samples might be optional in reality. Always review the schema against your API's documented contract before pushing it.

How does it pick required fields?

For a single object, every key is marked required (because every key is present). For an array of objects, only keys present in every object are marked required — keys appearing in some but not all become optional. That matches how validators read the schema: "this field must always be present".

What's the difference between Draft 2020-12 and Draft 7?

For 95% of schemas, nothing — the basic vocabulary is identical. Differences appear in advanced features: $dynamicRef replaces $recursiveRef, items replaces additionalItems for tuple validation, and a few keywords moved between vocabularies. If you're integrating with OpenAPI 3.1 or Ajv 8+, pick 2020-12; for older Ajv (v6), older Stoplight, or anything generated before 2019, pick Draft 7.

Why is my date detected as date-time and not date?

The order of detection is date-time before date, so 2024-01-15T00:00:00Z matches date-time first. 2024-01-15 alone matches date. If you want a date-only field that happens to include time, hand-edit the schema or strip the time component from your sample first.

Does the schema preserve enum-like fields?

No — inferring "this must be one of [active, paused, archived]" requires more samples than a typical paste contains, and false positives are dangerous (a single tenant flipping to a new state would break validation in production). Add enum: [...] by hand once you've reviewed your domain.

Can I use the output with OpenAPI?

Yes — drop the body of the schema (everything except $schema and $id) into a components.schemas.MyType entry. OpenAPI 3.1 supports the full Draft 2020-12 vocabulary; OpenAPI 3.0 supports a subset that's close to Draft 7 but with a couple of quirks (no nullable keyword on Draft 7 — OpenAPI 3.0 added its own).

JSON to JSON Schema Generator