GraphQL SDL: Validate and Format a Schema Online

Why validate GraphQL SDL before you merge?

A schema that does not parse blocks code generation, fails GraphQL server startup, and turns a review into guesswork. The usual culprits — a missing brace, an unknown type name, a forgotten Query root — hide in a 400-line SDL diff. FastMinify's GraphQL SDL validator runs GraphQL.js buildSchema in your browser: paste the schema document, get a valid/invalid verdict with line and column when GraphQL.js provides them. Formatting stays on Beautify GraphQL (Prettier). There is no separate format-graphql slug. Browse the rest of the cluster from the API tools hub. If you also maintain REST contracts, pair this workflow with the OpenAPI validation guide.

Catch SDL syntax errors and unknown types before CI or server boot

Line and column on issues when GraphQL.js reports locations

Schema stats: type count, Query / Mutation / Subscription fields

100% in the browser — your schema is never uploaded

Format queries and SDL separately with Beautify GraphQL (Prettier)

Honest limits and habits that survive code review

What validate-graphql does not do

A valid verdict means GraphQL.js buildSchema accepted the pasted SDL. It is not a proof that your API behaves correctly in production.

No query or mutation execution — no resolver calls, no variable coercion against live data

No introspection of a running server — paste the schema document you own

No fetch of remote .graphql files, includes, or Git URLs

No GraphQL Federation / supergraph compose — one SDL document per paste

512 KiB UTF-8 maximum on the validator — huge monoliths need local tooling

Single file, local check, then CI

The browser tool is for a fast loop before git push. Teams still run GraphQL.js, graphql-eslint, or rover in CI as the merge gate.

Keep one schema file (or a bundled SDL) for the paste to match what CI sees

Do not treat FastMinify as a billing or uptime monitor for your GraphQL endpoint

Document whether the repo uses a default Query type or a custom schema { query: … }

If you also ship OpenAPI, validate that contract separately — see the OpenAPI guide

For JSON Schema instances, use json-schema-validator — a different meta-model

Review habits that catch real breakage

Most SDL incidents are rename leftovers and missing roots, not exotic GraphQL features.

After every type rename, paste the full schema — not only the hunk

Require a Query root (or an explicit schema definition) in the same PR as new types

Beautify before asking for review so field lists are visible in the GitHub diff

Copy the validator error into the PR description when CI logs are noisy

Keep formatting options (2 vs 4 spaces) aligned with the repo Prettier config

Schema SDL vs queries: two documents, two tools

What GraphQL SDL actually is

Schema Definition Language (SDL) describes types, fields, and roots. It is the contract your resolvers must honour — not an executable query. FastMinify validates that contract with GraphQL.js buildSchema, not by talking to a live server.

Object types, interfaces, enums, unions, scalars, and input objects

Root fields on Query, Mutation, and Subscription when those types exist

The results panel counts those types and root fields after a successful parse

SDL is a document you paste — FastMinify does not fetch .graphql files from a URL

A valid verdict means GraphQL.js accepted the schema document, not that production resolvers match it

Queries, mutations and fragments do not belong here

An operation document (query, mutation, subscription, fragment) is not schema SDL. Pasting one into the validator fails buildSchema. Format those documents on Beautify GraphQL instead.

Validate GraphQL accepts schema SDL only — buildSchema, no query execution

Beautify GraphQL formats both schema SDL and operation documents via Prettier's GraphQL parser

Codegen and Apollo/Yoga still need a valid schema; pretty-printing a query will not fix an unknown type

There is no GraphQL query runner and no live introspection on FastMinify

If you need JSON payload checks for REST, use the JSON validator — it does not understand SDL

The Query root is usually required

GraphQL.js typically requires a Query root type unless your schema definition names another query type. A document of only type User { … } with no query root usually fails validation — that is expected, not a FastMinify bug.

Minimal valid paste: type Query { hello: String }

Custom root: schema { query: RootQuery } plus type RootQuery { … }

Missing Query is one of the most common "it works in my editor" surprises

Undefined types fail with a message such as Unknown type "Foo" — often with a line number

Some semantic errors omit locations; the verdict is still invalid

Validate vs beautify: do not swap them

Validation answers "is this schema SDL accepted by GraphQL.js?". Beautify answers "is this GraphQL readable?". Indentation never fixes an unknown type.

Validate: buildSchema — valid or invalid, issues with line/column when available

Beautify: Prettier — tabWidth 2 or 4, tabs, printWidth 80 / 100 / 120

JavaScript Prettier knobs (semicolons, quotes, trailing commas) do not apply to GraphQL

Recommended order: validate SDL → fix types → beautify → open the PR

Beautify can format a query that validate-graphql will correctly reject as non-SDL

Validate then format: a practical workflow

Using the GraphQL SDL validator

Open the GraphQL validator, paste a single schema document (max 512 KiB UTF-8), and wait for the debounced verdict. The results panel shows Valid or Invalid, the first error with line and column when known, a copy-error action, and schema stats when parse succeeds.

Paste schema SDL only — not a query, not a remote endpoint URL

Live validation in the editor — no upload, no account

Stats after a good parse: types, Query fields, mutations, subscriptions

Copy the error message into the PR when you need a paper trail

512 KiB cap — larger schemas belong in local GraphQL.js or CI

Format with Beautify GraphQL

The GraphQL beautifier pretty-prints schemas and operations with Prettier. Use it for review diffs — it does not replace validate. Options: 2 or 4 spaces or tabs, plus print width. Browse all formatters on the beautify tools hub.

Readable SDL for humans — nested fields unwrapped

Same Prettier engine as the rest of the FastMinify formatter family

Syntax errors surface with line hints — fix and retry

Queries and fragments are welcome here; they are not welcome on validate-graphql

Chain validate → beautify so reviewers see a typed, indented schema

Scenario — Unknown type in a pull request

A teammate renamed Pet to Animal but left pet(id: ID!): Pet on Query. CI or the server fails with little context in the GitHub overlay.

Step 1: Paste the schema into validate-graphql

Open validate-graphql. An invalid verdict with Unknown type "Pet" (and a line when available) points at the stale field.

Step 2: Fix the type name or restore the type

Either rename the field return type to Animal or add type Pet back. Re-paste until the panel shows a valid schema.

Step 3: Beautify and commit

Run the fixed SDL through beautify-graphql, download or copy, and update the PR. Reviewers read types, not a one-line blob.

Scenario — Unreadable SDL before a schema review

A generated or minified-looking schema lands in the repo. Reviewers cannot see which fields sit on Query versus Mutation.

Step 1: Beautify first if you cannot even read it

Paste into beautify-graphql. Prettier unwraps nested selections and type bodies. This step does not prove the schema is valid.

Step 2: Validate the formatted document

Copy the pretty SDL into validate-graphql. Confirm the Query root exists and that every named type is defined.

Step 3: Check the stats tiles

Type count and root-field counts help you spot an empty Query or a schema that accidentally dropped mutations. Then commit the formatted file.

Conclusion

Validate GraphQL SDL in the browser with buildSchema, then format with Prettier — locally, without sending the schema anywhere. That loop catches unknown types and missing Query roots before CI or a gateway. It does not replace a running server, introspection, or federation compose. For REST contracts, stay on the API hub; for readable queries, stay on Beautify GraphQL.

Validate or format your GraphQL now

Paste schema SDL into validate-graphql before every schema PR

Do not paste queries into the validator — format them on Beautify GraphQL

Expect a Query root unless your schema definition names another type

Treat a valid verdict as GraphQL.js acceptance, not production proof

Chain validate → beautify, then keep CI as the merge gate