JSON Schema Generator

What is JSON Schema?

JSON Schema is a declarative language for defining the structure, content, and constraints of JSON data. Think of it as a blueprint: just as a building blueprint specifies what materials to use and where walls go, a JSON Schema specifies what types of values are allowed, which fields are required, and what constraints apply. JSON Schema is defined by an IETF specification (currently Draft 2020-12, with Draft 7 being the most widely adopted version in production).

Our generator takes sample JSON data and reverse-engineers a JSON Schema Draft 7 document from it. It detects data types, identifies string formats (email, URL, date-time), maps nested structures, and marks all present fields as required. All processing happens in your browser — your data stays private.

Why JSON Schema Matters

Without schema validation, JSON is just "whatever string parses." That works until someone sends "age": "thirty" instead of "age": 30 and your application crashes. JSON Schema provides:

• Validation — reject invalid data at the boundary before it enters your system. Catch type mismatches, missing required fields, and out-of-range values automatically.
• Documentation — schemas are machine-readable documentation. Tools like Swagger/OpenAPI render them into interactive API docs automatically.
• Code generation — generate TypeScript interfaces, Python dataclasses, Go structs, and validation code directly from schemas.
• API contracts — schemas define the agreement between API producer and consumer. Both sides can validate independently without coordinating.
• Testing — generate realistic mock data from schemas for unit and integration tests.

JSON Schema Types Explained

JSON Schema supports seven primitive types. Each type has its own set of validation keywords:

string

Validates text values. Common constraints:

{
  "type": "string",
  "minLength": 1,
  "maxLength": 255,
  "pattern": "^[a-zA-Z]+$",
  "format": "email"
}

Built-in string formats: email, uri, date-time, date, time, ipv4, ipv6, hostname, uuid, regex.

number / integer

Validates numeric values. integer is stricter — it rejects decimals like 3.14.

{
  "type": "integer",
  "minimum": 0,
  "maximum": 150,
  "exclusiveMinimum": 0,
  "multipleOf": 1
}

boolean

Only accepts true or false. No constraints beyond the type itself.

null

Only accepts the value null. Often combined with another type: {"type": ["string", "null"]} to indicate a nullable field.

object

Validates JSON objects. This is where most of the schema logic lives:

{
  "type": "object",
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age": { "type": "integer", "minimum": 0 },
    "email": { "type": "string", "format": "email" }
  },
  "required": ["name", "email"],
  "additionalProperties": false
}

• properties — defines the schema for each known property.
• required — lists which properties must be present. Properties not in this list are optional.
• additionalProperties — when set to false, rejects any property not listed in properties. Useful for strict validation.

array

Validates JSON arrays with control over item types and array length:

{
  "type": "array",
  "items": { "type": "string" },
  "minItems": 1,
  "maxItems": 100,
  "uniqueItems": true
}

• items — the schema that each array element must conform to.
• minItems / maxItems — constrain the array length.
• uniqueItems — when true, all elements must be distinct.

Real-World JSON Schema Examples

User Profile Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "User Profile",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "username": {
      "type": "string",
      "minLength": 3,
      "maxLength": 30,
      "pattern": "^[a-zA-Z0-9_]+$"
    },
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "minimum": 13, "maximum": 150 },
    "roles": {
      "type": "array",
      "items": { "type": "string", "enum": ["admin", "user", "editor"] },
      "minItems": 1,
      "uniqueItems": true
    },
    "profile": {
      "type": "object",
      "properties": {
        "bio": { "type": "string", "maxLength": 500 },
        "website": { "type": "string", "format": "uri" },
        "avatar_url": { "type": ["string", "null"], "format": "uri" }
      }
    }
  },
  "required": ["id", "username", "email"]
}

API Error Response Schema

{
  "type": "object",
  "properties": {
    "error": {
      "type": "object",
      "properties": {
        "code": { "type": "integer" },
        "message": { "type": "string" },
        "details": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "field": { "type": "string" },
              "issue": { "type": "string" }
            },
            "required": ["field", "issue"]
          }
        }
      },
      "required": ["code", "message"]
    }
  },
  "required": ["error"]
}

Composition Keywords: Combining Schemas

JSON Schema provides keywords for combining and composing schemas:

• allOf — data must be valid against ALL of the listed schemas. Used for inheritance: extend a base schema with additional properties.
• anyOf — data must be valid against at least ONE of the listed schemas. Used for union types: a field that accepts either a string or a number.
• oneOf — data must be valid against EXACTLY ONE of the listed schemas. Used for discriminated unions: a shape that is either a circle or a rectangle, but not both.
• not — data must NOT be valid against the given schema. Used for exclusions.

// A field that accepts string or number (anyOf)
{
  "anyOf": [
    { "type": "string" },
    { "type": "number" }
  ]
}

// A nullable string (oneOf with null)
{
  "oneOf": [
    { "type": "string", "minLength": 1 },
    { "type": "null" }
  ]
}

Using JSON Schema for Validation

JavaScript (ajv)

import Ajv from 'ajv';            // npm install ajv
import addFormats from 'ajv-formats'; // npm install ajv-formats

const ajv = new Ajv();
addFormats(ajv);

const schema = {
  type: 'object',
  properties: {
    name: { type: 'string', minLength: 1 },
    email: { type: 'string', format: 'email' }
  },
  required: ['name', 'email']
};

const validate = ajv.compile(schema);

const valid = validate({ name: 'Alice', email: 'alice@example.com' });
// → true

const invalid = validate({ name: '', email: 'not-an-email' });
// → false, validate.errors contains details

Python (jsonschema)

from jsonschema import validate, ValidationError  # pip install jsonschema

schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string", "minLength": 1},
        "age": {"type": "integer", "minimum": 0}
    },
    "required": ["name"]
}

# Valid data
validate(instance={"name": "Alice", "age": 30}, schema=schema)

# Invalid data — raises ValidationError
try:
    validate(instance={"age": "thirty"}, schema=schema)
except ValidationError as e:
    print(e.message)  # "'name' is a required property"

JSON Schema in OpenAPI / Swagger

If you build REST APIs, you almost certainly use OpenAPI (formerly Swagger). OpenAPI uses JSON Schema (with slight extensions) to define request bodies, response shapes, and query parameters. Generating a schema from your actual data is the fastest way to bootstrap an OpenAPI specification:

1. Paste a real API response into our generator to get a base schema.
2. Review and adjust: mark optional fields, add description text, set minimum/maximum constraints.
3. Copy the schema into your OpenAPI components/schemas section.
4. Reference it in your endpoint definitions with $ref.

Generated Schema vs. Hand-Written Schema

Our generator gives you a solid starting point, but auto-generated schemas always need review:

• Required fields may be wrong — the generator marks all fields present in the sample as required. In reality, some fields may be optional. Review the required array and remove fields that are not always present.
• Constraints are missing — the generator infers types but not business rules. Add minimum, maximum, minLength, maxLength, pattern, and enum constraints based on your domain knowledge.
• Descriptions are empty — add description to every property so the schema serves as documentation.
• Nullable fields need explicit handling — if a field can be null but your sample happened to have a value, you need to manually add "type": ["string", "null"].
• Enums are not detected — if a field only accepts specific values (like "status": "active" | "inactive"), add an enum constraint manually.

JSON Schema Best Practices

• Use additionalProperties: false for strict APIs — this rejects unknown fields, catching typos and preventing clients from sending unsupported data.
• Provide defaults — use the default keyword to document what value is assumed when a field is missing.
• Use $ref for reuse — define common structures (like an Address or Money object) once in definitions and reference them throughout the schema.
• Version your schemas — when your data model changes, create a new schema version rather than modifying the existing one. This prevents breaking existing consumers.
• Test with invalid data — a schema that accepts everything is useless. Test with intentionally wrong data (wrong types, missing fields, out-of-range values) to confirm it rejects correctly.
• Keep schemas close to the code — store schema files alongside the code that uses them, not in a separate documentation repository. This makes it easier to keep them in sync.
• Validate at system boundaries — validate incoming data at API endpoints, message queue consumers, and file readers. Don't validate internally between trusted functions.
• Start from real data — use our generator with actual production data samples rather than writing schemas from scratch. Real data catches edge cases you would not think of.