JSON Schema Editor

How to Build a JSON Schema Online

Building a JSON Schema from scratch used to mean writing verbose, nested JSON by hand — and spending more time debugging brace mismatches than thinking about your actual data model. This editor gives you a visual workflow that removes that friction. Here is the step-by-step process.

Step 1 — Import an existing schema or start fresh. If you already have a .json or .yaml schema file (for example, an OpenAPI component schema), click Import and paste or upload the file. The editor parses it and populates the visual tree immediately. If you are starting from scratch, skip the import and go straight to adding your first property.

Step 2 — Define properties and types. Use the editor's property panel to add each field. For every property you specify a name, a type (string, number, integer, boolean, array, or object), and whether it is required. For strings you can add constraints like minLength, maxLength, and pattern. For numbers you can add minimum, maximum, and multipleOf. Nested objects get their own sub-property trees, and arrays let you define the schema of the items they contain.

Step 3 — Validate against sample data. Once your schema is defined, switch to the Validate tab and paste a real JSON object. The editor runs validation and reports which fields pass and which fail, including the specific constraint that was violated. This tight feedback loop lets you catch ambiguous type definitions before they reach production.

Step 4 — Export the finished schema. Click Export to download the schema as a .json file, ready to drop into your codebase, API gateway, form validator, or Koodisi's integration platform.

What Is JSON Schema?

JSON Schema is a vocabulary for describing the structure and constraints of JSON data. It is itself written as a JSON document — a meta-document that says "a valid instance of my data must look like this." The JSON Schema specification is maintained by the OpenJS Foundation and has gone through several drafts. The most widely deployed drafts today are Draft-07 (used in many API frameworks) and Draft 2020-12 (the current stable release, with improved $ref handling and a cleaner vocabulary).

At the core, a JSON Schema document is a JSON object. The $schema keyword declares which draft applies. The type keyword constrains the value to a primitive type. The properties keyword maps field names to sub-schemas that describe each field. The required array lists which properties must be present. Together, these four keywords cover the vast majority of real-world validation scenarios:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id":    { "type": "integer" },
    "email": { "type": "string", "format": "email" },
    "age":   { "type": "integer", "minimum": 0, "maximum": 130 }
  },
  "required": ["id", "email"]
}

Beyond these basics, JSON Schema supports allOf, anyOf, and oneOf for composition — letting you combine multiple sub-schemas. The $ref keyword allows schemas to reference and reuse other schemas by URI, which is how large OpenAPI specifications avoid repetition. The $defs section (called definitions in Draft-07) is the conventional place to store reusable schema fragments.

JSON Schema is not just a validation tool. Teams use it for documentation, code generation (generating TypeScript interfaces from a schema), and as the single source of truth that aligns frontend, backend, and integration layers around the same data contract.

Generating JSON Schema from Sample JSON

One of the most popular use cases for a JSON Schema tool is JSON to JSON Schema generation — taking a real JSON object (a sample API response, a database record, a webhook payload) and inferring a schema from it automatically. This is valuable because it eliminates the tedious work of manually transcribing every field and type from a document you already have.

The generation process walks the JSON structure recursively. For each key-value pair it records the JavaScript type of the value and, for objects, recurses into sub-properties. For arrays it inspects a sample of the items to decide the item schema. The result is a Draft-07 or 2020-12 JSON Schema document that describes the shape of your sample data. Here is a simple example — given this JSON payload:

{
  "orderId": 10482,
  "status": "shipped",
  "customer": {
    "name": "Priya Patel",
    "email": "[email protected]"
  },
  "items": [
    { "sku": "WIDGET-01", "qty": 2, "price": 9.99 }
  ]
}

The JSON Schema generator produces:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "orderId":  { "type": "integer" },
    "status":   { "type": "string" },
    "customer": {
      "type": "object",
      "properties": {
        "name":  { "type": "string" },
        "email": { "type": "string" }
      }
    },
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "sku":   { "type": "string" },
          "qty":   { "type": "integer" },
          "price": { "type": "number" }
        }
      }
    }
  }
}

The generated schema is a starting point, not a finished contract. You will want to review it and add required arrays, string format constraints ("format": "email" for the email field), numeric ranges, and any enumeration constraints the sample data could not reveal. The visual editor makes these additions fast.

Auto-generation is especially useful when onboarding a third-party API: you capture a sample response in your JSON Editor, paste it into the schema generator, and within seconds have a schema ready to use as a contract test.

JSON Schema Validation: Why API Teams Need It

Modern APIs are distributed contracts. When a backend team changes the shape of a response payload — renaming a field, removing a previously-present key, changing a type from string to number — consumers break. JSON Schema validation is the mechanism that catches these breaks early, before they reach production.

Contract testing. By encoding the expected shape of every API request and response as a JSON Schema, teams can run automated contract tests that verify both sides of the API against the same schema. Consumer-driven contract testing (CDCT) frameworks like Pact use JSON Schema under the hood for this exact purpose.

Payload validation at the gateway. API gateways such as AWS API Gateway, Kong, and Azure API Management accept JSON Schema documents to validate incoming requests before they reach your service. Attaching a schema to your endpoint means malformed payloads are rejected at the edge — reducing error handling in downstream services and improving security posture against injection attacks that exploit unexpected field types.

Catching breaking changes. When a new version of an API is released, comparing the new schema against the old one in a Diff Viewer immediately surfaces every structural difference. A field that moved from required to optional, or a type that changed from integer to string, shows up instantly — giving you an audit trail of API evolution over time.

Form and input validation. Frontend frameworks like React Hook Form and libraries like Ajv and Zod all speak JSON Schema or can be configured with schemas produced by this editor. Sharing one schema between your API validation layer and your frontend form validation eliminates the classic bug where frontend and backend disagree on whether a field is required.

JSON Schema vs OpenAPI: How They Relate

A common point of confusion for developers encountering JSON Schema for the first time is the relationship between JSON Schema and OpenAPI. They are not the same thing — but they are deeply intertwined.

OpenAPI is a specification for describing entire REST APIs: endpoints, HTTP methods, parameters, authentication schemes, and response codes. JSON Schema is the sub-language OpenAPI uses to describe the shape of the data in those requests and responses. When you write an OpenAPI components/schemas object, you are writing JSON Schema.

OpenAPI 3.0 uses a dialect of JSON Schema Draft-04/05 with some additions and restrictions. OpenAPI 3.1 — the current version — upgraded to full JSON Schema 2020-12 compatibility, meaning schemas in an OpenAPI 3.1 document are valid JSON Schema 2020-12 documents. This alignment removes the awkward differences that made tooling interoperability painful in OpenAPI 3.0.

This editor bridges both worlds. If you have an OpenAPI 3.1 spec in YAML, you can import a specific components/schemas entry directly. Edit the schema visually, then export the updated JSON and paste it back. Because the exported schema is valid JSON Schema 2020-12, it works in OpenAPI 3.1 contexts without translation.

For teams building integrations on Koodisi's integration platform, this matters concretely: Koodisi's connector configuration accepts JSON Schema documents to define the shape of the data flowing between systems. Building those schemas here, then importing them into Koodisi, gives you a validated data contract before a single message is sent.

JSON Schema Use Cases for Integration Developers

Integration developers sit at the intersection of many data sources — REST APIs, databases, SaaS platforms, message queues — each with its own data model. JSON Schema is one of the most practical tools in the integration developer's toolkit because it provides a format-agnostic language for documenting and enforcing those data models.

API payload contracts. When connecting two systems via API, define a JSON Schema for the canonical shape of the message — the representation that both the source system's output and the target system's input must conform to. Transformations within the integration pipeline map raw source payloads to this canonical schema before sending them onward. Validation against the schema at both input and output catches mapping errors early.

Database schema documentation. NoSQL databases (MongoDB, DynamoDB, Firestore) have no enforced schema at the storage layer. JSON Schema serves as the documentation and the optional validation layer for document shape. MongoDB natively supports JSON Schema validation rules on collections, letting you enforce field presence and types at the database level without changing your application code.

Form validation. For internal tools and customer-facing forms built on top of integrations, JSON Schema drives dynamic form generation. Libraries like react-jsonschema-form and JSON Forms render input fields directly from a schema, keeping the field definitions DRY — one schema drives both validation and rendering.

ETL pipeline validation. In data engineering pipelines, schema validation between stages catches type drift — where a field that was always a number starts arriving as a string after an upstream system update. Checkpointing each pipeline stage with a JSON Schema validator turns silent data corruption into a loud, catchable error.

Importing YAML Schemas and Exporting JSON

JSON Schema is defined in JSON — but the tooling ecosystem often serializes it in YAML. OpenAPI specifications are almost universally written in YAML for readability. AsyncAPI, which describes event-driven APIs, uses YAML by default. Many Kubernetes CustomResourceDefinition (CRD) files embed JSON Schema validation rules in YAML.

This editor accepts both formats on import. When you import a .yaml file, the parser converts it to the internal JSON representation and populates the property tree. You can then edit the schema visually — add, remove, or change fields — and export the result as .json.

The export-as-JSON output is valid JSON Schema 2020-12. It can be used directly in any tool that consumes JSON Schema: Ajv (the most popular JavaScript validator), Pydantic (Python), Newtonsoft.Json Schema (.NET), or the schema registry of your choice. For teams that need YAML output, converting the exported JSON to YAML is a one-step operation using any YAML library or a simple online converter.

A common workflow for OpenAPI teams: export the full OpenAPI spec from your API management tool, extract the relevant components/schemas entry, import it here to visually inspect and edit, then export the updated schema and paste it back into the spec. This is faster and less error-prone than hand-editing nested YAML indentation.

Frequently Asked Questions

What JSON Schema draft version does this editor use?

The editor outputs JSON Schema Draft 2020-12 by default, which is the current stable specification. Draft-07 is also widely supported by validators, and the core vocabulary (type, properties, required, additionalProperties) is compatible across both drafts. If your target validator requires Draft-07, change the $schema URL in the exported file — the structural keywords are the same.

What is the difference between a JSON Schema editor and a JSON Schema generator?

A JSON Schema generator infers a schema from a sample JSON document automatically — you give it data and it produces a schema. A JSON Schema editor lets you manually build and modify schemas with a visual interface. This tool does both: you can generate a starting schema from a sample JSON object, then edit it in the visual panel to add constraints, required fields, and format annotations that auto-generation cannot infer.

Can I validate a JSON document against my schema in this editor?

Yes. Switch to the Validate tab, paste a JSON object, and the editor runs it through the schema immediately. Validation errors are reported per field, showing which constraint was violated and at what JSON path. This is useful for checking that your schema correctly accepts good data and rejects bad data before you deploy it.

Can I export the schema as YAML instead of JSON?

The current export produces .json output, which is the canonical format for JSON Schema. If you need YAML, the exported JSON can be converted with any YAML serializer (for example, js-yaml in Node.js, PyYAML in Python, or a dedicated online JSON-to-YAML converter). The content is semantically identical — YAML is a superset of JSON, so no information is lost in the conversion.

How do I use the exported schema in my code?

Download the .json file and load it into your preferred JSON Schema validator. In JavaScript, install ajv (npm), then:

import Ajv from "ajv";
import schema from "./my-schema.json";

const ajv = new Ajv();
const validate = ajv.compile(schema);

const valid = validate(data);
if (!valid) console.log(validate.errors);

In Python, install jsonschema (pip) and use jsonschema.validate(instance, schema). In .NET, Newtonsoft.Json.Schema and System.Text.Json.Schema both accept JSON Schema documents. The schema exported from this editor is standards-compliant and works with any of these libraries without modification.