type: [...] instead of anyOf.
What the generator infers
The generator walks your JSON sample recursively and infers a schema for each value. Here is exactly what each JSON value becomes:
| JSON value | Generated schema | Notes |
|---|---|---|
true / false | { "type": "boolean" } | |
1, 42 (whole numbers) | { "type": "integer" } | Uses integer, not number |
3.14, 9.99 (decimals) | { "type": "number" } | |
null | Simple: { "type": "null" }Smart: { "type": ["null","string",…] } | Smart Mode adds a refine hint |
"hello" | { "type": "string" } | With format hints — see below |
"2026-05-23T14:00:00Z" | { "type": "string", "format": "date-time" } | ISO 8601 pattern |
"2026-05-23" | { "type": "string", "format": "date" } | YYYY-MM-DD pattern |
"550e8400-..." | { "type": "string", "format": "uuid" } | UUID v4 pattern |
"alice@example.com" | { "type": "string", "format": "email" } | |
"https://..." | { "type": "string", "format": "uri" } | |
{ ... } (object) | { "type": "object", "properties": {...}, "required": [...] } | All non-null fields become required |
[...] (array) | { "type": "array", "items": ... } | Samples all elements; Simple uses anyOf, Smart uses type: [...] for mixed types |
The generated schema is a starting point
Auto-inference from a single sample is fast but not complete. A sample with one object cannot tell you which fields are truly optional, what the minimum/maximum values should be, or what the allowed enum values are. After generating, review and tighten the schema:
// Generated from: { "status": "active", "age": 28 }
{
"$schema": "https://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"status": { "type": "string" }, // ← tighten: add "enum": ["active","inactive","pending"]
"age": { "type": "integer" } // ← tighten: add "minimum": 0, "maximum": 120
},
"required": ["status", "age"] // ← review: is "age" truly required?
}
Once you have reviewed the schema, paste both the JSON and the schema into the JSON Schema Validator to confirm the validation works as expected.
Using the schema with Kafka Avro
JSON Schema and Avro schema are different formats — this tool generates JSON Schema, not Avro. However, the output is useful as a structure reference when writing Avro schemas by hand. The type mapping is:
| JSON Schema type | Avro equivalent |
|---|---|
"type": "string" | "type": "string" |
"type": "integer" | "type": "int" or "long" |
"type": "number" | "type": "float" or "double" |
"type": "boolean" | "type": "boolean" |
"type": "null" | "type": "null" |
"type": "object" | "type": "record" with "fields" |
"type": "array" | "type": "array" with "items" |
Read the companion guide: Kafka Avro Schema: Backward Compatibility Explained.
Understanding the Generator Modes
The generator has two modes to handle null values in your JSON sample:
Simple Mode (default)
Outputs strict JSON Schema draft-07 that matches jsonlint and most other tools. When a field is null, it becomes {"type":"null"} — technically valid but rarely useful for APIs.
// Input: { "deletedAt": null }
// Simple Mode output:
"deletedAt": { "type": "null" }
// Problem: ✗ Rejects any non-null value, even if the API sends a timestamp string
⚡ Smart Mode (production-ready)
Outputs nullable union types — the pattern real APIs use. Null fields get all possible types plus a description telling you to refine once you have real data.
// Input: { "deletedAt": null }
// Smart Mode output:
"deletedAt": {
"type": ["null","string","number","boolean","object","array"],
"description": "Type inferred as null only — refine after seeing non-null samples"
}
// Advantage: ✓ Accepts any type while you're building the schema
// Next step: Once you see { "deletedAt": "2026-05-23T14:00:00Z" }, refine to:
// "type": ["string","null"],
// "format": "date-time"
Smart Mode is unique to JSON Dev Tools — it solves the null-type trap that every other generator falls into. For a detailed explanation of why type: null is problematic and when to use each mode, see JSON Schema type: null — Why It's Wrong for Real APIs.
Frequently Asked Questions
What is a JSON Schema generator?
A JSON Schema generator reads a sample JSON document and automatically produces a JSON Schema describing its structure — field types, required fields, nested shapes, and array item types. The generated schema is a starting point: add constraints like minLength, enum, or pattern before using it in production.
Which JSON Schema draft does this tool output?
The generator outputs JSON Schema draft-07, the most widely supported draft. It sets $schema to https://json-schema.org/draft-07/schema# in every output. Draft-07 is compatible with Ajv 6+, OpenAPI 3.0, and most validation libraries.
Does the generator handle nested objects and arrays?
Yes. The generator recursively walks any depth of nesting. For objects it produces a properties map with required listing all non-null fields. For arrays it samples all elements and merges their schemas into an anyOf union if they have mixed types.
How does the tool detect formats like email and date-time?
The generator applies lightweight regex heuristics to string values: ISO 8601 date-time patterns produce format: date-time, UUID patterns produce format: uuid, HTTP URLs produce format: uri, and basic email patterns produce format: email. These are hints — validate them in the Schema Validator before using in production.
Can I use the generated schema with Kafka Avro?
The generated output is a JSON Schema, not an Avro schema. However it is useful as a structure reference when writing Avro schemas by hand — the field names, nesting depth, and nullability hints all transfer. See the Kafka Avro Schema guide for the type mapping between the two formats.
Is my JSON sent to a server?
No. All inference runs entirely in your browser using JavaScript. Your JSON never leaves your device.