JSON Schema Builder

JSON Schema Builder

The JSON Schema Builder helps you create JSON Schema definitions quickly, either by defining fields manually or generating a schema from sample JSON. Schemas define the structure, types, and rules for your JSON, which is essential for API contracts, configuration files, and data validation pipelines. This tool runs fully in your browser, keeping your data private.

Building a schema manually can be tedious, especially for nested objects. This builder accelerates the process by letting you add fields, set types, and mark required properties. You can also paste sample JSON and generate a schema automatically, then refine it for stricter validation.

What a JSON Schema includes

• Types: string, number, integer, boolean, object, array, null.
• Required fields: which keys must exist.
• Constraints: min/max length, enum lists, numeric ranges, patterns.
• Nested structures: objects and arrays with their own rules.
• Additional properties: allow or deny unexpected keys.

How to use the schema builder

1. Define fields or paste sample JSON on the left.
2. Generate the schema using the builder controls.
3. Review and edit the schema output on the right.
4. Validate your schema with JSON Schema Validator.

Example: schema from sample JSON

Input JSON:

{
  "id": 1,
  "email": "user@example.com",
  "active": true,
  "roles": ["admin", "editor"]
}

Generated schema (simplified):

{
  "type": "object",
  "required": ["id", "email", "active", "roles"],
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string" },
    "active": { "type": "boolean" },
    "roles": { "type": "array", "items": { "type": "string" } }
  }
}

Example: adding constraints

Schema with constraints:

{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id": { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "status": { "type": "string", "enum": ["active", "inactive"] }
  },
  "additionalProperties": false
}

Common errors and fixes

• Schema too permissive: If invalid data passes, add constraints like required, minLength, or enum.
• Schema too strict: If valid data fails, relax constraints or allow additional properties.
• Type mismatch: Update property types when your data changes or ensure your sample JSON represents real data.
• Nested rules missing: For arrays and objects, define items and nested properties.
• Invalid schema JSON: The schema itself must be valid JSON. Format it with JSON Formatter.

Best practices for schema design

• Start with a generated schema, then refine it.
• Use required sparingly for truly mandatory fields.
• Set additionalProperties to false for strict APIs.
• Document fields with description for clarity.
• Validate schemas against real production samples before release.

Schema evolution tips

APIs change over time. When you add a new field, avoid breaking existing clients by making it optional at first. Use oneOf or anyOf if you need to support multiple versions of a payload. Keep your schema in version control so you can track changes and roll back if needed.

For long-lived APIs, consider adding deprecated or descriptive metadata in your documentation (even if the schema itself does not enforce it) so consumers know which fields are legacy.

If you work with multiple teams, publish schemas in a central location so everyone validates against the same version. This reduces drift and makes integrations more reliable.

Field planning checklist

1. List all required fields and confirm they are always present.
2. Define types and constraints for each field.
3. Decide whether unknown fields should be allowed.
4. Test with multiple real-world samples.
5. Publish schema updates with clear change notes.

Keyword glossary (quick reference)

• type: data type for a field
• properties: object field definitions
• items: array element definition
• required: list of mandatory fields
• enum: allowed values for a field
• minimum/maximum: numeric bounds
• minLength/maxLength: string length bounds

Use these keywords to quickly refine schemas after automatic generation. A small number of well-chosen constraints usually improves validation without making schemas brittle.

Testing schemas with samples

After building a schema, test it against multiple real payloads. Include both valid and invalid samples to ensure error messages are meaningful. This helps you catch overly strict rules before production. You can also generate sample data with JSON Sample Generator and validate the results.

When schemas fail unexpectedly, check the exact error path to see which rule triggered the failure. Small changes like adjusting a minimum or allowing null values often resolve most issues.

For public APIs, publish the schema with your documentation so consumers can validate their payloads independently.

Use cases

API contracts: Define strict structures for request and response payloads.

Configuration validation: Ensure config files match expected structure.

Data pipelines: Enforce shape consistency for incoming data streams.

Documentation: Provide schemas alongside example payloads.

FAQs

Can I generate schemas automatically?
Yes. Paste sample JSON and generate a starting schema, then refine it.

Is my JSON uploaded?
No. Everything runs locally in your browser.

Which JSON Schema draft is supported?
Most Draft-07 style schemas work well for typical validation.

Can I validate the schema here?
Use JSON Schema Validator to validate JSON against your schema.

How do I allow optional fields?
Do not include them in the required list.

Can I handle arrays of objects?
Yes. Define items with nested properties.

What if my schema needs multiple shapes?
Use oneOf or anyOf for multiple valid shapes.

Why is validation failing?
Check types, required fields, and constraints, and validate against real sample data.

How do I test a schema?
Use JSON Schema Validator with multiple sample payloads.

Should I include examples in the schema?
Examples are useful for documentation, but they are optional. Include them if your team benefits from guidance.

How do I handle nullable fields?
Use type as an array (e.g., ["string","null"]) or use anyOf with null.

Can I describe arrays of complex objects?
Yes. Define items as an object schema with nested properties.

Do I need to include a $schema field?
It is optional but recommended, as it clarifies which schema draft your definition targets.

Can I reuse schemas across services?
Yes. Shared schemas help keep multiple services consistent.

What if I need conditional rules?
Use oneOf, anyOf, or if/then patterns where supported.