GraphQL Schema to JSON Schema Converter

Convert a GraphQL schema (SDL) into JSON Schema (draft 2020-12). Every type, input, interface, enum and union becomes an entry under ; scalar fields map to the right JSON types; non-null (!) fields are marked required while nullable fields get a null union; and lists become array types with the correct item nullability. Optionally choose one type as the root to emit a top-level . It runs entirely in your browser.

How to use the GraphQL Schema to JSON Schema Converter

Paste your GraphQL SDL — the type-system definitions, not a query — or open a .graphql file. Each object type, input and interface is converted to a JSON Schema object placed under $defs, with properties for its fields and additionalProperties: false. Enums become a string schema with an enum list, and unions become an anyOf of $refs to their members. The five built-in scalars map directly: Int to integer, Float to number, String and ID to string, Boolean to boolean; custom scalars become an unconstrained schema, since JSON Schema can't know their shape.

The conversion's careful part is nullability, which GraphQL and JSON Schema express oppositely. In GraphQL a field is nullable by default and ! makes it required and non-null; in JSON Schema a property is optional by default and you list the required ones. So a GraphQL ! field is added to the object's required array, while a nullable field has null added to its type (or is wrapped in an anyOf with {"type":"null"} when it references another type). Lists map to array, and the tool tracks whether the items are non-null ([Post!]) separately from whether the list itself is ([Post!]!). After converting, pick a root type from the dropdown to add a top-level $ref if you want the schema to validate one specific type; leave it as "schema library" to keep all definitions available under $defs for reuse.

Mapping the GraphQL type system to JSON Schema

GraphQL and JSON Schema both describe the shape of data, but they were built for different jobs. GraphQL SDL defines an API's type system — the objects, inputs, enums and their relationships — and the server enforces it. JSON Schema validates arbitrary JSON documents and is understood by a huge ecosystem of validators, form generators, code generators and documentation tools. Converting from one to the other lets you reuse a GraphQL type definition wherever JSON Schema is the lingua franca: validating webhook payloads, generating forms, configuring an LLM's structured output, or feeding a contract-testing tool.

The mapping is mostly mechanical but has real subtleties. Object, input and interface types become JSON Schema objects under $defs, the conventional place for reusable subschemas, and references between them become $ref pointers — so a User with a posts: [Post!]! field yields an array whose items $ref the Post definition, exactly mirroring the GraphQL graph. Enums map to a string with an enum constraint, and unions to anyOf. The scalar mapping is direct for the five built-ins; custom scalars like DateTime have no universal JSON Schema equivalent, so they convert to an unconstrained schema you can tighten with a format or pattern afterward.

The conceptual mismatch that matters is nullability, because the two systems invert the default. GraphQL treats every field as nullable unless marked !; JSON Schema treats every property as optional unless named in required, and a value can only be null if null is among its allowed types. A faithful converter therefore has to do two things for each field: add non-null fields to required, and add null to the type of nullable ones. It must also distinguish the nullability of a list from the nullability of its elements — [Post!], [Post]! and [Post!]! are three different contracts. This tool implements those rules so the generated schema accepts exactly the documents the GraphQL type would, giving you a correct, draft-2020-12 starting point rather than an approximation that passes some inputs and silently rejects others.

Common use cases

  • Validate payloads. Reuse a GraphQL input type as a JSON Schema to validate webhook or API request bodies.
  • Structured LLM output. Turn a GraphQL type into the JSON Schema a model uses to constrain its response.
  • Form and code generation. Feed JSON-Schema-based generators from your existing GraphQL definitions.
  • Contract documentation. Export a $defs library so other tools can reference your types by $ref.

Frequently asked questions

How are non-null and nullable fields converted?
A non-null field (marked ! in GraphQL) is added to the object's required array. A nullable field is left out of required and has null added to its allowed types — directly for scalars (e.g. ["string","null"]) or via an anyOf with {"type":"null"} when it references another type. This mirrors that GraphQL is nullable-by-default while JSON Schema is optional-by-default.

How do GraphQL scalars map?
Int maps to integer, Float to number, String and ID to string, and Boolean to boolean. Custom scalars (such as DateTime) have no universal JSON Schema equivalent, so they become an unconstrained schema — add a format or pattern afterwards if you need to validate their contents.

What happens to enums, interfaces and unions?
An enum becomes a string schema with an enum list of its values. Object types, inputs and interfaces become JSON Schema objects under $defs. A union becomes an anyOf of $refs to its member types. References between types are emitted as $ref pointers into $defs.

How are list types handled?
A list becomes an array type, and the converter tracks item nullability separately from list nullability. So [Post!]! is a required array of non-null Post items, [Post!] is a nullable array of non-null items, and [Post] is a nullable array whose items may be null — each producing the correct items schema and required placement.

What is the root type option for?
By default the output is a library of definitions under $defs with no single entry point, which is ideal when you want to reference several types. Selecting a root type adds a top-level $ref to it, turning the document into a schema that validates that one type directly while keeping the others available under $defs.