GraphQL → TypeScript Types

Overview

Converts GraphQL type definitions into TypeScript interfaces. Fields typed String or ID become string, Int or Float become number, Boolean becomes boolean, list types become arrays, and custom object types keep their name as the property type. Nullability is preserved faithfully: a field without an exclamation mark becomes an optional TypeScript property. Output updates live with copy and download controls.

How It Works

Paste your SDL schema, such as type User { id: ID! username: String! email: String age: Int roles: [String!]! }, into the left editor. Each type block in the schema is emitted as a TypeScript export interface on the right, with one property per field. Fields lacking the non-null marker appear with a question mark so TypeScript forces you to handle their possible absence. Copy or download the generated types from the output panel.

Step-by-Step Usage Guide

1. Paste your GraphQL SDL into the left editor.
2. Watch the TypeScript interfaces appear on the right as you type.
3. Check which fields came out optional; those were nullable in your schema.
4. Copy or download the generated types into your project's types file.

Technical Specifications & Standards

The converter maps the GraphQL scalar system onto TypeScript's, and the nullable mapping is the part worth understanding. In GraphQL, String! means the field is always present, while String means it can be null, so the tool emits username: string for the first and email?: string for the second; the optional property is the honest translation, and it is why code that consumes these interfaces must null-check fields that were nullable in the schema. List types are mapped to arrays with their inner type resolved: [String!]! becomes string[]. Custom object types are emitted as their own name, so an Address field typechecks only if the schema also declares type Address and the converter emits that interface too; there is no import or namespace resolution. What is not supported is as important as what is: the parser matches type Name { ... } blocks with a regular expression, so input, enum, interface, union, and scalar declarations are ignored entirely, and enums are not generated as TypeScript unions. Comments and field arguments are also dropped. For a full schema with those constructs, generate with graphql-codegen instead; this tool targets the common case of plain object types where a quick, readable interface is the goal.

Targeted Use Cases

• Generating typed response models from a small API schema without adding codegen tooling.
• Learning how GraphQL nullability translates into TypeScript optionality.
• Producing quick interfaces for a schema fragment while prototyping a client.
• Aligning frontend types with backend SDL during a design review.

Notes & Gotchas

• Declare every referenced object type in the input; a custom field type is emitted as a bare name and will not typecheck otherwise.
• Do not expect enums, inputs, unions, or interfaces to be converted; only type blocks are parsed.
• Review optional fields against your data access layer, since nullable schema fields become properties that can be undefined.
• Regenerate rather than hand-editing when the schema changes, so the two cannot drift.

Frequently Asked Questions