INPUT - JSON
OUTPUT - JSON Schema
Output will appear here
100% client-side
Output will appear here
Generate JSON Schema definitions from sample JSON data with our free JSON Schema generator. The tool reads every element of every array rather than sampling the first, so a key that only appears late in the file still reaches the schema; it separates optional keys from nullable values; it infers enum values for string fields that repeat a small set of labels; and it auto-detects formats such as email, URI, date and date-time. A fixture suite compiles each generated schema with Ajv and validates it against the document it came from, so a schema that would reject the data it was inferred from fails the build. Use it for API documentation in OpenAPI, form validation, or automated configuration file checks.
Try Convert All - paste JSON once, see TypeScript, Go, YAML, and 15 more formats instantly.
Paste a representative JSON object in the input editor. The richer your sample data, the more accurate the generated schema will be.
The output shows a JSON Schema 2020-12 definition with type constraints, required fields, format annotations, and nested object schemas.
Copy the schema or download the .json file. Use it for API documentation (OpenAPI), form validation, or CI pipelines that validate config files.
The output declares $schema as JSON Schema 2020-12, the current draft, which is what the "date" and "uuid" format annotations require. Ajv validates it via its 2020 build, and Python jsonschema selects the right validator from the $schema keyword automatically.
Yes, but only when every sampled value agrees. Emails get "format": "email", full timestamps get "date-time", bare calendar dates get "date", and UUIDs, IPv4 addresses and URIs get their own formats. If one value in a field is a UUID and the next is not, the field is left as a plain string rather than annotated with a format that half the data fails.
OpenAPI 3.1 is a superset of JSON Schema 2020-12, so the output drops into components/schemas directly. For OpenAPI 3.0, which predates 2020-12, replace nullable unions such as "type": ["string", "null"] with "type": "string" plus "nullable": true and remove the $schema keyword.
Every element of the array is merged, not just the first. When the elements are objects, the result is a single object schema whose properties cover every key seen anywhere in the array, with only the keys present in all of them marked required. When they are different primitive types, the items schema lists them together as "type": ["string", "integer"], which accepts each of them without the exclusivity trap that oneOf carries when the branches overlap.
No, and deliberately. A sample document cannot show you a property that is absent from it, so emitting additionalProperties: false would turn a gap in your sample into a rule that rejects valid data. Add the keyword yourself once you know the contract.
By default, nested objects are represented inline within the parent schema for simplicity. For very deep structures you may choose to refactor them into separate definitions manually.