JSON Schema validation

Processed locally

app.schema.view

You can also load data via #data={"name":"Ada"} or #url=... It is cleared from the address bar after it is read.

Infer a JSON Schema from a sample JSON document. Useful when you already have a real response and still need API docs or a starting point for a validator. Review required fields and enums by hand—the tool only sees “what this example contains,” not “what the product must have.”

Start from an example

Objects, arrays, strings, and numbers map to the matching type. Nested objects are expanded into properties where possible.

If an array is empty, item types may be wrong. Add a real element and infer again.

Treat it as a draft

Inference cannot know whether a field is required—you still edit required. Optional fields, enums, and format (email, uri) also need a human pass.

Hand the result to ajv or similar in CI. That is more reliable than a verbal agreement.

Generated locally

Sample data is not uploaded. Still redact production samples first.

Output includes a $schema declaration so other tools can recognize the version.

Example

Sample JSON

{
  "id": 1001,
  "name": "Ada",
  "active": true
}

Inferred Schema (excerpt)

{
  "type": "object",
  "properties": {
    "id": { "type": "number" },
    "name": { "type": "string" },
    "active": { "type": "boolean" }
  }
}

Can I use it to validate another JSON document?

This page focuses on generating a Schema from a sample. Hand the result to ajv or similar on the backend or in CI for validation.

What about nesting and arrays?

Inference walks down as far as it can. Empty arrays without an item sample may get the item type wrong.

When should I use the GraphQL page instead?

Use Schema for REST / JSON docs. Use the type-inference page for GraphQL services.

Will it mark format: email?

Type inference is the priority. Add email and other formats to the Schema based on the product.

Recommended workflow

Prepare a successful response sample with as many fields as possible.
Generate the Schema and check that types and properties look right.
Add required, enum, additionalProperties, and other constraints by hand.
Use it in mocks / CI to validate later responses, and pair it with Diff for version review.

One example cannot produce a complete contract. Cross-check several samples, then tighten the Schema.