b2KIT

GraphQL to TypeScript

Generate TypeScript types and interfaces from GraphQL schema definitions and query documents.

Tested tool guide Tested browser tools Checked August 16, 2026

What GraphQL to TypeScript does and how it behaves

GraphQL to TypeScript turns GraphQL schema definitions and operation documents into TypeScript declarations that mirror the types available to application code. Schema input can describe objects, inputs, enums, scalars, lists, and nullability; operation input narrows results to the fields a query actually selects. The important distinction is scope: a schema type represents the full GraphQL contract, while a query result represents one selection set. Users often expect those shapes to be identical, but an operation can omit fields, rename them with aliases, or define a separate variables shape.

How the result is produced

1

Schema type mapping

Schema definitions establish the source type graph. GraphQL object and input fields become TypeScript properties, named GraphQL types become reusable declarations, and list wrappers become array-shaped types. Nullability applies at every wrapper level: String!, [String]!, and [String!]! express different contracts. Built-in scalars have conventional TypeScript counterparts, but the meaning of a custom scalar cannot be determined from its name alone.

2

Operation result shapes

Query documents define selection-specific types. A result shape follows the response keys in the operation's selection set, including aliases, instead of copying every field from the corresponding schema object. Variable declarations form a separate input shape. Fragment selections can contribute fields to the result, but determining those fields' TypeScript types still requires the schema definitions that declare their GraphQL return types.

Good uses

  • Create a TypeScript response type for one query before passing its selected fields into a component, resolver test, or application service.
  • Replace handwritten interfaces after GraphQL object fields, input objects, enums, or operation selections have changed.
  • Inspect how nested lists, nullable fields, aliases, fragments, and operation variables affect the TypeScript contract for a GraphQL request.

Limits and checks

  • A custom scalar name does not reveal its JavaScript representation. Review any generated declaration for scalars such as DateTime, JSON, Decimal, or UUID before relying on it.
  • Generated operation types reflect the schema and document supplied to the tool. They do not prove that a deployed server currently exposes the same schema.
  • GraphQL nullability and TypeScript optionality are different concepts. A nullable GraphQL field may return null; that alone does not mean its response key is optional or absent.

Common questions

Can a query document alone provide complete response types?

Usually no. A query names fields but does not state each selected field's return type. The corresponding schema supplies whether a field returns a scalar, object, enum, list, or nullable value. Variable declarations provide GraphQL input type names, but those named input types also require schema definitions for complete TypeScript shapes.

Do the generated types validate GraphQL responses at runtime?

No. TypeScript types and interfaces describe values for static checking and are not runtime validators. They cannot establish that a server response matches the pasted schema or operation after the TypeScript declarations have been erased. Runtime response validation requires a separate validation step based on an appropriate schema or explicitly defined runtime checks.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools