Compare GraphQL Schemas Online
Paste two GraphQL SDL schemas. See what types, fields, and arguments were added, removed, or changed — line by line.
🔒 100% private — runs entirely in your browseror try sample data
Paste two GraphQL SDL schemas. See what types, fields, and arguments were added, removed, or changed — line by line.
🔒 100% private — runs entirely in your browseror try sample data
GraphQL Schema Diff compares two GraphQL Schema Definition Language (SDL) files and shows you exactly which types, fields, arguments, and directives were added, removed, or modified. Whether you are reviewing a pull request that changes your schema, auditing changes between API versions, or verifying that a code-first schema generator produces the expected output, this tool gives you a clear, color-coded view of every change.
GraphQL schemas define the contract between your API and its consumers. A seemingly small change — renaming a field, changing a return type from User! to UserPayload!, or adding a required argument — can break every client that depends on the old schema. Comparing schemas visually before deploying helps catch breaking changes, missing deprecation notices, and unintended type modifications before they reach production.
Paste your SDL from any source — rover graph introspect, graphql-codegen output, schema files in your repository, or the SDL export from tools like Apollo Studio, Hasura, or Postgraphile. The comparison runs entirely in your browser so your API schema stays private. For introspection JSON output, use the API Response Diff tool instead.
# v1 schema
type User { id: ID! name: String! email: String! posts: [Post!]!
} # v2 schema — multiple breaking changes
type User { id: ID! name: String! email: String! # still required — safe avatar: String # new nullable field — safe role: UserRole! # new required field — BREAKING for fragments posts(status: PostStatus): [Post!]! # new argument — safe (optional)
} # The diff highlights:
# + avatar: String (safe addition)
# + role: UserRole! (breaking: required non-null)
# ~ posts → posts(status: PostStatus) (safe: optional arg)Adding a non-null field without a default is a breaking change for clients using fragments. The diff tool makes these additions immediately visible.
# Before: mutations return types directly
type Mutation { createUser(input: CreateUserInput!): User! deleteUser(id: ID!): Boolean!
} # After: mutations return payload types (best practice)
type Mutation { createUser(input: CreateUserInput!): UserPayload! deleteUser(id: ID!): DeletePayload!
} type UserPayload { user: User errors: [Error!]
} type DeletePayload { success: Boolean! errors: [Error!]
} # Diff shows the return type changes and new payload typesMigrating from direct return types to payload types is a common schema evolution pattern. The diff clearly shows which mutations changed and what new types were introduced.
# v1
enum PostStatus { DRAFT PUBLISHED ARCHIVED
} # v2 — added REVIEW, which is a safe change
# But removing an enum value would be breaking
enum PostStatus { DRAFT REVIEW # new value — safe for servers PUBLISHED ARCHIVED
} # New union type
union SearchResult = User | Post # Diff highlights the new REVIEW value
# and the entirely new SearchResult unionAdding enum values is safe for server schemas but can be breaking for clients that use exhaustive switches. The diff tool shows all enum changes so you can assess the impact.
GraphQL SDL does not define a canonical field order, so different tools may output types with fields in different sequences. When comparing schemas from two different sources (e.g., introspection vs hand-written SDL), fields may appear reordered. The diff tool shows these as removed-and-added lines. Sort your types and fields consistently before comparing to reduce noise.
GraphQL SDL supports string descriptions (triple-quoted or single-line) above types and fields. These descriptions are part of the schema and serve as documentation for clients. Changes to descriptions will appear in the diff. While not functionally breaking, documentation changes are worth reviewing since they affect API explorer tools and generated client docs.
Custom directives and some built-in directives (like @deprecated) may or may not appear in schema exports depending on your tooling. If one schema was generated from introspection and the other from source SDL, directive differences may be artifacts of the export method rather than real schema changes. Use the same export method for both schemas when possible.
Paste both GraphQL SDL schemas into the two panels and click Compare. The tool highlights added, removed, and modified lines with word-level detail so you can see exactly which types, fields, arguments, or enum values changed.
The tool shows all text-level differences between schemas. Breaking changes like removed fields, changed return types, removed enum values, and new required arguments appear as removed or modified lines. You identify the semantic impact from the highlighted changes — look for removed lines, changed nullability (!), and modified return types.
Use introspection or CLI tools. With Apollo Rover: rover graph introspect http://localhost:4000/graphql. With graphql-codegen: configure the SDL output plugin. With Hasura: export from the console. With code-first frameworks (Nexus, TypeGraphQL, Pothos): print the schema using printSchema() from the graphql package.
Yes. This tool runs entirely in your browser using client-side JavaScript. Your GraphQL schemas, including internal types, custom directives, and API structure, are never sent to any server.
For introspection query results (JSON format), use the API Response Diff tool which performs deep JSON comparison. This GraphQL Schema Diff tool is optimized for SDL text comparison with line-by-line and word-level diffs.
For federated schemas, compare each subgraph schema individually rather than the composed supergraph. This gives you a clearer picture of what changed in each service. For schema stitching, you can compare the merged output, but be aware that type extensions from different sources will be interleaved.