GraphQL SDL schema

Validation results

Results will appear here after validation...

What is GraphQL Schema Validator?

GraphQL Schema Definition Language (SDL) describes the entire surface area of a GraphQL API — every type, query, mutation, subscription, and the relationships between them. A schema with syntax errors, duplicate type names, or references to types that do not exist will cause the server to crash at startup or return confusing runtime errors. This validator performs structural analysis on your SDL text, checking brace balance, type uniqueness, field references, and root type presence so you can catch problems before deploying to staging or production.

How to Use

Paste your complete GraphQL SDL schema into the text editor on the left.
Press the "Validate Schema" button to start the analysis.
Errors (red) block the schema from loading — fix these first.
Warnings (yellow) indicate best-practice gaps like a missing Query type.
Info items (blue) are advisory, such as unused type definitions.
Re-validate after each round of fixes until no errors remain.

Why Use This Tool?

Catches duplicate type definitions that would cause compile-time failures in every GraphQL server implementation

Detects field references to types that are never defined in the schema

Validates brace balance so unclosed type blocks are found immediately

Warns when the required Query root type is absent from the schema

Identifies unused types that may be dead code or leftover from refactoring

All validation runs entirely in your browser — no schema data is transmitted anywhere

Tips & Best Practices

Every valid GraphQL schema must define a "type Query" even if your API is mutation-heavy
Use the non-null marker (!) intentionally: String! guarantees the field is never null, but over-using it makes your schema rigid
Understand the difference between [Post]! (non-null list that may contain nulls) and [Post!]! (non-null list of non-null items)
Input types (defined with the "input" keyword) cannot reference interfaces or unions — they only accept scalar and enum types
For production CI/CD pipelines, pair this browser tool with graphql-inspector or graphql-eslint for automated schema linting on every commit

Frequently Asked Questions

What is the difference between a schema error and a warning?

Errors indicate problems that will prevent the schema from compiling — duplicate type names, references to undefined types, or unbalanced braces. Warnings flag best-practice violations that will not stop the server from starting but may cause unexpected behavior, such as a missing Query type or empty type bodies. Info items are advisory notices like unused type definitions.

Does this tool validate GraphQL queries against a schema?

No — this validator checks the schema definition itself (SDL syntax and structure), not individual query documents. To validate a query against a schema you need a full GraphQL execution engine such as graphql-js. For building queries visually, try the GraphQL Builder tool.

Can I validate schema fragments or partial SDL files?

Yes, but be aware that undefined type references will be flagged as errors because the validator has no knowledge of types defined in other files. When validating a partial schema, you can safely ignore "unknown type" errors for imported types and focus on syntax and duplicate errors instead.

When should I NOT use this validator?

This tool is not suitable for validating GraphQL query syntax, checking federation directives (like @key or @extends), or testing runtime resolver behavior. It also cannot validate schema-first vs code-first approaches — it only works with raw SDL text. For federation validation, use Apollo Rover or the GraphQL Federation CLI.

Is my schema data kept private?

Absolutely. All validation logic runs as client-side JavaScript in your browser. Your GraphQL schema is never sent to any external server, API, or third-party service. You can safely validate proprietary or confidential schemas without any data leaving your machine.

Why does the validator flag my custom scalar as an unused type?

Custom scalars defined with "scalar MyScalar" are only referenced when a field explicitly uses them as a type. If no field in your schema references the scalar, it will appear as an unused type. This is informational — you may keep the scalar for future use or remove it to keep the schema clean.

Real-world Examples

Catching an Undefined Type Reference Before Deploy

A developer adds a "Post" field to the User type but forgets to define the Post type. The validator catches this as an error before the schema reaches staging.

Input

type User { id: ID! name: String posts: [Post!]! }

Output

Error: Unknown type reference: "Post" is used but never defined in this schema

Detecting a Missing Query Root Type

A team builds a mutation-only API and forgets to include a Query type. The validator warns that the schema will not load without it.