GraphQL Schema Formatter
Format and validate GraphQL schema definitions.
Overview
Paste a GraphQL SDL schema and get back a consistently formatted version - types, enums, interfaces, unions, and inputs aligned, fields sorted (optionally), descriptions normalised to block-string form, and trailing whitespace cleaned. Basic validation catches the obvious mistakes (duplicate type names, missing colon, malformed directive arguments).
It's for API authors maintaining a hand-written GraphQL schema, and reviewers looking at SDL diffs. Reach for it when merging schema changes from multiple contributors, syncing a hand-written .graphql file with codegen output, or preparing a public schema for documentation.
How it works
The formatter parses against the GraphQL SDL grammar from the October 2021 spec - type, interface, union, enum, scalar, input, directive, plus the extend variants. Each definition is re-emitted with two-space indentation, descriptions promoted to triple-quoted block strings, and directives placed on the same line as their owner.
Optional field sorting is alphabetical within each type. Definitions stay in source order so schema diffs remain meaningful unless you opt into sorting top-level definitions too.
Examples
- Type with arguments:
type Query { user(id: ID!): User posts(limit: Int = 20, offset: Int = 0): [Post!]! } - Description as block string:
""" Represents an authenticated user. """ type User { id: ID! name: String! } - Enum:
enum Role { ADMIN EDITOR VIEWER } - Union with directive:
union SearchResult @deprecated(reason: "Use SearchHit") = Post | Comment
FAQ
Does it validate against the spec?
It catches structural errors (parse failures, duplicate definitions). Cross-reference validation (does this User actually exist?) needs a schema-aware tool.
Should I sort fields?
Sorting helps with diff stability when teams add fields independently, but obscures intent when field order is semantic. Most schemas leave fields in source order.
Are comments preserved?
The SDL spec defines descriptions (block strings before a definition) but not # comments inside types. Description strings are preserved; loose comments may be dropped.
Does it handle schema extensions (extend type)?
Yes - extend type Query { ... } blocks are formatted alongside their base definitions.