JSON to OpenAPI Schema

Generate an OpenAPI 3.0 schema from a JSON sample in YAML or JSON format.

Load Preset Sample

Input JSON

Output Format

About JSON to OpenAPI Schema

Convert a JSON sample object into a complete OpenAPI 3.0 schema definition. The tool automatically infers types — strings, integers, floats, booleans, arrays, and nested objects — and generates a schema you can copy directly into your API documentation. Output in either YAML or JSON format.

Built and maintained by Meet Shah · Last updated 18 July 2026

What this tool is used for

Producing an OpenAPI schema fragment from a real response.
Documenting an endpoint that has no specification.
Getting a starting schema you then annotate with formats and descriptions.
Producing YAML or JSON to paste into an existing spec.
Comparing two responses' schemas to spot a breaking change.

Frequently Asked Questions

Which OpenAPI version does this target?: It matters, because the schema dialects differ. OpenAPI 3.0 uses a MODIFIED subset of JSON Schema — notably nullable: true instead of a type array — while 3.1 is fully JSON Schema 2020-12 compliant and uses type: [string, null].
What is the difference from a plain JSON Schema?: OpenAPI adds API-specific keywords JSON Schema has no concept of: example, deprecated, discriminator for polymorphism, and readOnly/writeOnly to distinguish request from response shapes. It is a superset shaped for HTTP contracts.
How should shared models be organised?: Under components/schemas, referenced with $ref. Inlining the same object in ten endpoints means ten places to update and produces ten duplicate classes in every generated client — the commonest structural mistake in hand-written specs.
Can required be inferred from a sample?: No, and assuming it is dangerous. A field present in one example may be optional; a field absent may be required but omitted. OpenAPI's required is an explicit array, and generation can only guess at it.
Why does the spec drive code generation?: Because tools generate clients, servers and mocks from it — so an inaccurate schema propagates into every consumer's type definitions. That is the argument for writing the spec first rather than deriving it from a sample response.
How are nullable fields expressed?: It changed between versions. OpenAPI 3.0 uses `nullable: true` alongside the type; 3.1 aligns with JSON Schema and uses a type array such as `["string", "null"]`. Mixing the two forms is a common source of validator disagreement.
What are examples for, and where do they go?: They document realistic values and are rendered in the docs UI. Put them at the schema or property level rather than only on the response, so generated clients and mock servers can use them too.

Common errors and gotchas

Shipping the generated schema unedited, since it describes one example rather than the contract.
Assuming every present field is required, which a sample cannot establish.
Losing format hints such as date-time or email, which look like plain strings to a generator.
Producing a nullable field the wrong way, since 3.0 and 3.1 express it differently.
Overlooking array element variety, where the shape comes from the first element only.