JSON to OpenAPI Schema Generator

Paste a sample JSON value and generate an OpenAPI 3.0 schema object -- types, required, nested properties, nullable -- ready to paste into components.schemas.<Name>.

Private by architecture: All processing is 100% client-side memory. Your data never leaves this browser tab.

Schema name (optional)

Output format

Sample JSON

0 lines · 0 charsJSON

OpenAPI schema (YAML)

0 charsYAML

About This Tool

Writing an OpenAPI components.schemas entry by hand from an example API response is the same mechanical walk as writing a plain JSON Schema, with a few dialect differences: no $schema or $id meta keys, and nullable fields use nullable: true next to a base type instead of a type array. This tool runs the same shape inference as JSON Schema Generator and reshapes the result into that dialect, output as YAML (matching how most OpenAPI specs are authored) or JSON.

If you want plain, standalone Draft-07 JSON Schema instead -- for a $ref-based validator, not an OpenAPI spec -- use JSON Schema Generator. To go the other direction, from a full Postman collection to an OpenAPI spec, see Postman to OpenAPI.

Key Features

OpenAPI 3.0 dialect: no $schema/$id, nullable: true instead of a null type.
YAML or JSON output: toggle without re-running inference.
Recursive type inference: built on the same engine as JSON Schema Generator: objects, arrays, and primitives at every depth.
Optional schema name: sets a title, matching the key you'd give it under components.schemas.
File upload & drag-and-drop: load a .json file directly instead of pasting.
Keyboard-driven: Cmd/Ctrl+Enter to generate, Cmd/Ctrl+Shift+C to copy the output.

Example

Sample input:

{"id": 1, "name": "Ada", "nickname": null}

generates (YAML):

type: object
required:
  - id
  - name
  - nickname
properties:
  id:
    type: integer
  name:
    type: string
  nickname:
    nullable: true

Frequently Asked Questions

How is this different from the JSON Schema Generator tool?

They share the same shape-inference logic, but target different dialects. JSON Schema Generator outputs plain, standalone Draft-07 JSON Schema with a $schema key -- the dialect $ref-based tooling and this site's JSON Schema Validator expect. This tool strips that out and reshapes the result into the OpenAPI 3.0 schema dialect (no $schema/$id, nullable: true instead of a null type) so it drops straight into components.schemas.<Name> of a spec.

How are nullable fields represented?

OpenAPI 3.0 has no type: ["string", "null"] array form. A field whose only observed value is null becomes { nullable: true } with no base type -- edit in the real type once you know it, since one sample can't reveal whether the field is normally a string, a number, or something else.

Is the "required" list accurate?

Same caveat as JSON Schema Generator: with one sample to learn from, every key present in it is listed as required. Treat it as a draft to prune, not a guarantee.

Why offer both YAML and JSON output?

Most OpenAPI specs are authored in YAML, so that's the default. Some tooling and some specs are JSON-based instead, so a toggle switches the same schema object to JSON formatting without changing any of the inferred structure.