GraphQL SDL

TypeScript

What this converter does

You have a GraphQL schema. Your frontend is TypeScript. Somewhere in the middle you need a set of types that match the schema field-for-field, and you want them now — not after a five-minute codegen build, not after wiring up graphql-code-generator to a fresh project, not after explaining to a junior dev which plugin to install. Paste the GraphQL SDL in the left panel and the right panel returns idiomatic TypeScript: interface for object and input types, enum for enums, plain type aliases for unions and scalars.

The mapping follows the rules most TypeScript code expects. Built-in scalars line up with their TypeScript primitive equivalents: String and ID become string, Int and Float become number, Boolean becomes boolean. Custom scalars like DateTime default to string with a // custom scalar marker so you remember to widen them later. Non-null fields (name: String!) emit as required properties; nullable fields emit with the ? modifier. List types [Order!]! become Order[]. type Order implements Node becomes interface Order extends Node — the GraphQL interface relationship maps cleanly to TS structural extension.

No upload, no network, no AI. The conversion happens client-side in a hand-rolled SDL tokenizer — your schema never leaves the page, which is what you want when the schema is internal or pre-release.

How to use it

Three steps. Conversion is automatic — no Convert button.

Paste, upload, or load the sample

Drop your SDL into the left GraphQL SDL panel. As soon as you stop typing, the right panel updates. Click Upload for a .graphql / .graphqls / .gql file, or Sample to load a realistic e-commerce schema. A small chunk of SDL looks like this:

type Order implements Node { id: ID! placedAt: DateTime! status: OrderStatus! items: [OrderItem!]! } enum OrderStatus { PENDING PAID SHIPPED DELIVERED CANCELLED }

Both server-style schemas (with extend type Query) and standalone type definitions work. Block-string descriptions ("""...""") are picked up and emitted as JSDoc comments above the generated type, which is the convention the GraphQL reference implementation documents.

Read the generated TypeScript

The right panel emits types grouped by kind: scalars first, then enums, unions, interfaces, input types, and finally object types. Within each group, definitions stay in source order so the diff against your hand-written types is as small as possible. If the SDL has a parse error (unbalanced braces, an unterminated block string, etc.) the output panel shows a single // Invalid GraphQL: ... comment instead of throwing — the same pattern Apollo Server uses when its startup parse fails.

Copy or download

Hit Copy to paste the types straight into a schema.types.ts file in your project. Hit Download to save them as a .ts file. Output is plain text — no module imports, no runtime code — so it drops into any TS project, frontend or backend.

When you would actually use this

Quick types without setting up codegen

You are prototyping a frontend against an existing GraphQL endpoint and you do not want to spin up a full codegen pipeline just to get types for three queries. Paste the schema, copy the output into types.ts, ship the prototype. You can switch to a proper codegen pipeline later when the project is real.

Sanity-check what codegen will emit

Before adding a new type to the schema, paste the proposed SDL here to see what shape your TypeScript callers will end up with. Sometimes a field that reads fine in SDL produces awkward TS — an optional list of nullables, an enum with a value that collides with a TS reserved word — and it is much cheaper to find that here than after the PR has been merged.

Documenting a schema for a TypeScript-heavy team

Onboarding a TS-first team to a GraphQL API? Paste the schema, copy the generated types into the wiki. Engineers who think in TS interfaces grok the schema faster from a TS view than from raw SDL — the data shapes are the same, the syntax is just one they already read fluently every day.

Disposable scripts that hit a GraphQL endpoint

A one-off CLI tool, a Node script, an admin task — anything where you want some types around the response without committing to a full codegen setup. Paste, copy, type the response, run the script. Disposable, but type-safe enough to not embarrass yourself.

Common questions

Does it generate operation types (Query / Mutation result types), or just schema types?

Just schema types — the types declared in the SDL. Operation result types depend on the specific query or mutation a client runs, and that is exactly the job graphql-code-generator with the typed-document-node plugin is built for. This page covers the schema half: every type, interface, enum, input, union, and scalar in your SDL becomes a TS declaration.

How are nullable vs non-null fields handled?

Non-null fields (name: String!) emit as required, non-optional TS properties: name: string;. Nullable fields (name: String) emit as optional: name?: string;. The output stays clean — no | null unions everywhere — which is what most consumers want. If you want strict null checks instead, run a find-and-replace on the output.

What about list types like [Order] or [Order!]!?

Lists become TS arrays. [Order!]! emits as Order[] on a required field. [Order] emits as Order[] on an optional field. The element-level nullability is collapsed for readability — if you need it preserved you can switch a generated T[] to (T | null)[] by hand, but in practice almost no real codebase reads the inner-nullability separately.

How are custom scalars handled?

Custom scalars (anything that is not ID, String, Int, Float, or Boolean) default to string with a // custom scalar marker so they are easy to find and widen. For a DateTime scalar you might widen to string | Date; for a JSON scalar you might widen to unknown or a typed shape. The default of string matches what most servers send over the wire as JSON.

Is my schema sent to a server?

No. The conversion runs entirely in your browser — the SDL is tokenized client-side and the TypeScript output is rendered directly into the right panel. Nothing is uploaded, nothing is logged. Safe to paste internal or unreleased schemas.

Will the output round-trip back to the same SDL?

No — and it is not meant to. The output is TypeScript, which is a different language. Pasting the TS output back into the SDL panel will produce a parse error. If you want to format your GraphQL SDL itself, use the GraphQL Formatter linked below; it is built for that.

Other GraphQL tools

Generating types is one piece. These tools handle the rest of the GraphQL workflow:

GraphQL Schema to TypeScript