JSON to GraphQL Schema

Paste any JSON document and get a valid GraphQL Schema Definition Language (SDL) draft you can drop into your schema.graphql file. The tool walks every property, infers the GraphQL scalar (Int, Float, String, Boolean, ID), builds nested type definitions for objects, and emits [T] list types when it sees arrays. Mark any field as nullable or required with the toggle — the default treats present fields as non-null, which matches what most REST-to-GraphQL wrappers want.

How to use the JSON to GraphQL Schema

Paste a representative JSON sample (one full record is enough). Set the root type name — this becomes the top-level type emitted. The generator infers child types for nested objects (named after the JSON key, capitalized) and lists for arrays. Booleans become Boolean, integers Int, fractional numbers Float. The id/_id heuristic upgrades those fields to GraphQL's built-in ID scalar. Use the output as a starting point — review nullability and add custom scalars (DateTime, JSON, BigInt) where the inference is too generic.

About JSON to GraphQL Schema

GraphQL's Schema Definition Language is the canonical way to declare types, fields, and relationships in a GraphQL API. Hand-writing SDL from an existing REST payload is mechanical work — every field needs a name, a scalar, and a nullability marker, and every nested object needs its own type block. This generator does the mechanical part so you can focus on the design decisions: which fields should be union types, which arguments do you want on root queries, which fields need pagination wrappers.

The output is intentionally minimal. There are no resolvers, no Query root, no input types — just the data shape. That's the right scope: you'll wire those into your framework (Apollo, GraphQL Yoga, gqlgen, graphql-go, Hot Chocolate, etc.) using its own conventions. The generator never sees your sample data — everything runs in your browser, so you can paste production payloads without worrying about leaks.

Common use cases

  • Wrapping a REST API in GraphQL — start from a sample response, generate the SDL, then add resolvers that call the upstream REST endpoint.
  • Documenting an existing internal API — emit the shape, paste into your design doc as a reference for what consumers see today.
  • Mock servers — feed the generated SDL into a mocking tool like GraphQL Mesh or Apollo Server's mock mode to get a stub backend running in minutes.
  • Schema diffing — generate today's shape, generate tomorrow's, diff to confirm a payload change is non-breaking for GraphQL consumers.

Frequently asked questions

Does it generate resolvers?
No — only the SDL type definitions. Resolvers are framework-specific and depend on your data source, so they belong in your codebase rather than in the generator.

How does it handle null values in the sample?
A field with a null value is emitted as nullable (no !) regardless of the non-null toggle. If you want it required, replace the null with a representative value before generating.

What about arrays with mixed types?
The generator picks the first element's type and uses that for the list. Heterogeneous arrays usually mean you want a union or interface — design that explicitly rather than relying on inference.

Why is everything named after the JSON key?
It's the most predictable mapping. Rename freely in the output; SDL is plain text. The root type takes the name you set in the form.