GraphQL Schema Validator: Catch Structural Mistakes Early
A typo in GraphQL SDL — a missing colon, a duplicated type name, a field referencing a type that doesn't exist — often doesn't surface until your server fails to boot or a client query mysteriously breaks. This tool statically checks your schema definition language for exactly these classes of mistakes before you wire it into a running server.
Type references are checked against both GraphQL's five built-in scalars and every type name declared elsewhere in your input.
Why Undefined Type References Matter
A field like `author: User!` only works if `User` is actually declared somewhere in the schema (or is a built-in scalar). Typos in type names are a common source of confusing GraphQL server startup errors — this tool cross-references every field's type against everything it found declared in your input, flagging anything unrecognized.
Catching Duplicate Type Names
Two `type User { ... }` declarations in the same schema is invalid GraphQL, but the second definition can silently shadow the first in some tooling until it causes a hard-to-trace bug — this validator flags the duplication immediately.
Field Syntax Validation
Each line inside a type or interface body should match `name: Type` or `name(args): Type` — with optional list wrapping (`[Type]`) and non-null markers (`Type!`). A line that doesn't fit this shape (often a missing colon or a stray word) is flagged with the exact offending line.
Practical Examples
Catching a Missing Colon
A field written as `friend Comment` instead of `friend: Comment`.
- 1.Paste the schema
- 2.Result: 'could not parse field' error pointing at the exact line
Catching a Duplicate Type
Two separate `type User { ... }` blocks in the same input.
- 1.Paste the schema
- 2.Result: 'Duplicate type name' error
What Gets Checked
- Balanced braces, parentheses, brackets, and strings
- Field syntax inside type/interface bodies
- Enum value syntax
- Duplicate type/interface/input/enum names
- Field type references against known types
Good Use Cases
- Catching typos before deploying a GraphQL server
- Reviewing a schema change in a pull request
- Debugging why a schema fails to load
- Sanity-checking a schema pasted from documentation
Frequently Asked Questions
What does this actually check?
Four concrete things: balanced braces/parens/brackets and string literals, that every type/interface field line parses as a valid "name: Type" declaration, that no type name is declared twice, and that every field's type reference points to either a GraphQL built-in scalar (String, Int, Float, Boolean, ID) or another type declared somewhere in your schema.
Is this a full GraphQL SDL grammar validator?
No — it's a lightweight structural checker built with regex-based parsing, not a complete GraphQL SDL grammar implementation (which would need a proper lexer/parser for the full spec, including directives with complex arguments, interfaces implementing multiple interfaces, and schema extensions). It catches the most common real mistakes without requiring a full parser.
Why does it warn about undefined type references instead of erroring?
A type reference might be defined via a federation extension, a separate imported schema file, or a custom scalar registered elsewhere that this tool has no visibility into — so an unrecognized type name is flagged as a warning to double-check, not treated as a hard error.
Does it validate enum values?
Yes — each line inside an enum body must be a bare identifier (optionally followed by directives), matching GraphQL's enum value syntax.
Is my schema sent anywhere?
No, validation happens entirely in your browser.