Input

Output

What is the GraphQL Formatter?

A GraphQL schema that came out of a code generator, a federation composer, or a copy-paste from a chat window almost never has the whitespace you want. Types run together, fields share a line, descriptions get jammed up against the next definition. The GraphQL schema definition language is supposed to be the readable contract between your frontend and backend — but only if it is actually formatted. Paste your SDL into the left panel and the right panel returns it beautified: two-space indentation, one field per line, arguments inline, and any block-string descriptions kept above the type or field they document.

The pretty-printer is hand-rolled — no graphql npm package is loaded into the page, so first paint stays small. It tokenises the SDL, walks the brace structure, and re-emits with consistent spacing per the October 2021 GraphQL spec. Every SDL construct that shows up in real schemas is handled: type, interface, union, enum, input, scalar, extend, schema, directive, list and non-null modifiers ([Foo!]!), default values, directives, and triple-quoted descriptions. The formatter is idempotent — already-pretty SDL round-trips back unchanged, so you can safely run it inside a CI gate or a pre-commit hook.

Everything runs in your browser. No upload, no schema stored anywhere. Paste, beautify, copy.

How to Use the GraphQL Formatter

Three quick steps. The buttons described below are the actual buttons on this page.

Paste, Upload, or Load a Sample

Paste a GraphQL schema into the left Input panel — formatting happens automatically a fraction of a second after you stop typing, so there is no Convert button to hunt for. Click Upload for a .graphql, .graphqls, or .gql file, or hit Sample to load a realistic e-commerce Order schema. A typical messy paste looks like this:

type Order{id:ID! placedAt:DateTime! customer:Customer! items:[OrderItem!]!} type OrderItem{sku:String! name:String! quantity:Int! unitPrice:Money!}

Both server-style schemas (with extend type Query) and standalone type definitions work. The shapes accepted match what tools like Apollo Server parse at startup.

Read the Beautified Output

The right Output panel renders the beautified SDL with two-space indentation. Each field, enum value, and union member gets its own line. Arguments stay inline on the field line so signatures read naturally. Descriptions written as block strings ("""...""") are kept above the type or field they describe, which is how the Relay GraphQL specification recommends documenting a schema. If the SDL has unbalanced braces or any other parse error, the formatter surfaces a friendly inline message — it never throws or crashes.

Copy or Download

Hit Copy to grab the formatted schema for a pull request, doc, or chat. Hit Download to save as .graphql. The clear button on the input panel resets you to a blank state. Formatting happens entirely client-side — your schema never leaves the page.

When You'd Actually Use This

PR Review Readability

A teammate opens a PR that adds five new types to your schema. The diff looks like one giant block because the codegen output stripped formatting. Run the file through the formatter, then drop the beautified version into the PR description so reviewers can actually read what is being added. Following GraphQL schema best practices is much easier when reviewers can see the structure.

Schema Registry Diffs

Most schema registries (Apollo Studio, GraphQL Hive, Hasura) show diffs as line-by-line text. If one revision was minified and the next was pretty, every line shows as changed and the real change vanishes in the noise. Beautify both versions before uploading — same formatter, same output, real diff.

Docs and Onboarding

Writing public docs for a GraphQL API or onboarding a new engineer? Paste the schema in, copy the formatted version into the wiki or README. A schema with descriptions visible above each type is a much friendlier starting point than the unformatted blob the codegen tool spat out.

Pre-commit and CI Gates

Because the formatter is idempotent, you can run it as a pre-commit hook or a CI check: format the schema, fail the build if the result differs from the committed file. No more whitespace drift between contributors, and no more PRs where half the diff is reformatting noise.

Common Questions

Does it validate my schema, or just format it?

Just format. The formatter checks brace and quote balance well enough to pretty-print, but it does not verify that Query exists, that referenced types are defined, or that directive arguments match their definitions. For full validation, run your schema through the reference graphql-js implementation or your server's startup checks.

Is my schema sent to a server?

No. Formatting runs entirely in your browser. Nothing is uploaded, nothing is logged. Safe to paste internal or unreleased schemas.

Does it handle block-string descriptions?

Yes. Triple-quoted descriptions ("""An order placed by a customer.""") are preserved and emitted on the line above the type or field they document. This is the canonical way to write SDL documentation per the GraphQL spec.

What about directives and custom scalars?

Both are kept. @deprecated, @key, and any custom directive stay inline on the field. Custom scalars like scalar DateTime are emitted as their own line. The formatter does not try to interpret directive semantics — that is up to your server.

Will already-formatted SDL get re-formatted?

It is idempotent — beautifying already-beautified SDL produces the same output. So you can run the formatter in a CI check or a paste-and-compare workflow without worrying about whitespace drift.

How big a schema can I paste?

Anything your browser comfortably renders. Schemas of a few hundred types are no problem. Past 5 MB the Ace editor itself starts to slow down — that is the bottleneck, not the parser.

Other GraphQL Tools

Formatting is one part of working with GraphQL. These tools handle the rest: