GraphQL Schema Diff
Compare two GraphQL schemas — see additions, removals, and field-level type changes at a glance
Schema A (old)
Schema B (new)
Diff
What is the GraphQL Schema Diff?
Every API change breaks somebody's client. The first thing you need before merging a schema PR is a clear list of what actually changed — not a 600-line GitHub diff that mixes whitespace, reformatting, and real changes into one wall of red and green. Paste your old schema on the left, the new one on the right, and this tool gives you three lists: what was added, what was removed, and which existing fields changed type. The schemas are parsed per the October 2021 GraphQL specification, so what the tool considers a "type" or a "field" matches what your server considers one.
The diff is structural, not textual. Reordering fields inside a type is invisible. Reformatting the SDL is invisible. Renaming an argument shows up. Switching Int to Float on Order.total shows up. New enum values like OrderStatus.REFUNDED show up under additions. Removing a union member shows up under removals. The output style matches the categorisation that GraphQL Inspector and Apollo schema checks use, so the workflow translates to those tools when you eventually move the check into CI.
Everything runs in your browser. No upload, nothing logged. Safe for unreleased internal schemas.
How to Use the GraphQL Schema Diff
Paste, paste, read. There is no Compare button — the diff updates as you type.
Paste the Old Schema in Panel A
Drop the current production schema into the left panel labelled Schema A (old). Click Upload for a .graphql, .graphqls, or .gql file, or hit Sample to load a paired starter / iteration example. The schema does not have to be pretty — formatting differences are ignored.
Paste the New Schema in Panel B
Drop the candidate schema (the one in your PR) into the right panel labelled Schema B (new). The tool tokenises both schemas, walks every type definition, and recomputes the diff a fraction of a second after you stop typing. The reference parser semantics follow graphql-js closely enough that what shows here is what your server would see.
Read the Three Lists
The bottom panel has three sections. Additions (green) lists new types, new fields, new enum values, and new union members. Removals (red) lists the same categories in reverse — these are usually the breaking changes, so scan this list first. Changes (amber) lists fields and arguments whose type changed, like Order.total: Int → Float. If the schemas are equivalent, you get a single green banner saying so.
When You'd Actually Use This
PR Review
A teammate opens a PR that adds five new fields and renames an argument. The GitHub diff is unreadable because they also ran the schema through a formatter. Paste both versions here and get the real change list — usually three or four items long, not three hundred. Reviewers can argue about the actual semantics instead of arguing about indentation.
Catching Breaking Changes
Removing a field, narrowing a return type, or renaming a required argument are breaking changes for clients in the wild. The Removals and Changes lists surface them directly. Run the diff before merging to confirm the breaking change is intentional. The same check belongs in CI eventually — see the Apollo schema checks docs for the production version of this workflow.
Onboarding Documentation
When a new engineer asks "what changed last sprint?", paste the Monday version and the Friday version into the panels and copy the diff into your sprint notes. Faster than scrolling through commits and a lot more readable.
Federation Composition Sanity Check
After running a federated composer like Apollo Rover, paste the previous composed schema and the new one. The diff tells you whether the composition picked up the change you expected from the subgraph PR — or whether something silently changed elsewhere.
Common Questions
Does the diff catch breaking changes specifically?
Anything in the Removals and Changes lists is potentially breaking — removing a field, narrowing a return type, renaming an argument. The tool does not classify each change as "breaking" vs "non-breaking" the way GraphQL Inspector does, but the structured list makes it obvious which ones to look at.
Is field order considered a change?
No. Reordering fields inside a type is structurally identical and is ignored. Same for reordering enum values, union members, and arguments. Only added, removed, or type-changed items are reported.
What about descriptions and comments?
Block-string descriptions and comments are ignored when comparing structure. Adding a description to a field does not show up in the diff. If you want to track doc changes, do that in the formatted SDL diff in your PR, not here.
Are my schemas sent to a server?
No. The tokeniser and diff run entirely in your browser. Nothing is uploaded, nothing is logged. Safe to paste internal or unreleased schemas.
How big a schema can I paste?
The page caps each input at 5 MB. Past that the Ace editor itself starts to lag. Schemas of a few hundred types are no problem.
Can I run this in CI?
For local sanity checks before pushing a PR, this page is fine. For CI gates that fail the build on a breaking change, use the dedicated GraphQL Inspector CLI or Apollo schema checks — both have proper exit-code semantics and policy configuration.
Other GraphQL Tools
Diffing is one part of working with GraphQL. These tools handle the rest: