GraphQL Viewer
View GraphQL SDL with proper indentation, one field per line, descriptions kept above their type
Input
Output
What is the GraphQL Viewer?
If you have ever pasted a chunk of GraphQL SDL that came back on one line and tried to read it, you know the problem. Types, fields, arguments, directives, and union members all collapse together and the structure disappears. This tool fixes that. Paste your schema into the left panel and the right panel renders it with 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. It handles every SDL construct you actually see in the wild: type, interface, union, enum, input, scalar, extend, schema, list and non-null modifiers ([Foo!]!), default values, directives, and triple-quoted descriptions. Already-pretty input round-trips back unchanged.
Everything runs in your browser. No upload, no schema stored anywhere. Paste, read, copy.
How to Use the GraphQL Viewer
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. Click Upload for a .graphql, .graphqls, or .gql file, or hit Sample to load a realistic e-commerce schema. Quick example of what minified SDL looks like:
type Order{id:ID! placedAt:DateTime! customer:Customer! items:[OrderItem!]! total:Money! status:OrderStatus!} 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.
Read the Formatted Output
The right Output panel renders the parsed 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 other parse errors, the viewer surfaces a friendly message instead of crashing.
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. Parsing happens entirely client-side — your schema never leaves the page.
When You'd Actually Use This
Schema Pull Request Reviews
Reviewing a schema PR and the diff is hard to read because the file went through a code generator that stripped formatting? Paste the new version in here, eyeball the structure, then go back to the diff with a clearer mental model of what changed. Especially useful when the team is iterating on what counts as a good schema design.
Federation and Subgraph Debugging
Debugging an Apollo federation gateway and the composed supergraph schema comes back as one giant blob? Paste the merged SDL in, find the type that is misbehaving, see which subgraph contributed which field. The federation directives that show up in the output are documented alongside the rest of the schema syntax.
Documenting an API
Writing public docs for a GraphQL API your team owns? Drop the schema in the viewer, copy the formatted version into the wiki or README. The tree shape of types, interfaces, and unions reads naturally once it is laid out one field per line.
Onboarding New Engineers
A new teammate is trying to learn the shape of your GraphQL API. A formatted schema with descriptions visible above each type is a much friendlier starting point than the unformatted blob in the codegen output.
Common Questions
Does it validate my schema, or just format it?
Just format. The viewer 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, use the reference graphql-js implementation or pass it through your server's startup checks.
Is my schema sent to a server?
No. The pretty-printer 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 viewer does not try to interpret directive semantics — that is up to your server.
Will already-formatted SDL get re-formatted?
It is idempotent — pretty-printing already-pretty SDL produces the same output. So you can run the viewer 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
Viewing is one part of working with GraphQL. These tools handle the rest: