Format GraphQL operations, fragments and schema definitions into one canonical layout by parsing them for real — long argument lists break one per line, and syntax errors come back with line and column. Free, no sign-up — runs locally in your browser.
GraphQL's formatting problem
GraphQL documents live an untidy life: generated by clients,
embedded as template strings, copied out of playgrounds,
nested inside component files where the indentation answers
to the surrounding code instead of the query. Readability
suffers exactly where it matters — deep selection sets, where
a misplaced brace changes what a query fetches. This
formatter parses the document into its real structure and
re-prints it canonically: selection sets expanded one field
per line, definitions separated by a blank line, argument
groups kept inline when they fit and broken one-per-line
when they do not. Because it parses rather than pattern-
matches, it also doubles as a syntax check with positioned
errors — the unbalanced brace is caught here, not by your
API server at runtime.
How to use this tool
- Paste the document — a query, mutation, subscription, fragment, or a schema definition — or upload/drop a
.graphql file. - With “Format as I type” on, the result updates as you edit; otherwise press Format GraphQL.
- Pick 2 or 4 spaces; the rest of the style is fixed and opinionated, deliberately — one canonical layout is the point of a formatter.
- Copy or download the result. Your input is never rewritten in place, so the original survives beside the formatted version for diffing.
Scope, stated honestly
The grammar covered is the working language: executable
documents (operations with variables, defaults and
directives; fragments and inline fragments; aliases; nested
arguments including objects and lists) and the schema
family — type, interface,
input, enum, union,
scalar, schema,
directive and extend definitions,
with block-string descriptions preserved. What this tool is
not is a schema-aware validator: without your
schema it can judge structure, not truth — a perfectly
formatted query can still name a field that does not exist.
Run it for layout and syntax; keep your schema validation in
your own toolchain.
Worked example
The one-line query:
query GetUser($id: ID!) { user(id: $id) { name friends(first: 10) { name } } }
formats to the shape every GraphQL reader expects:
query GetUser($id: ID!) {
user(id: $id) {
name
friends(first: 10) {
name
}
}
}
Frequently asked questions
Does formatting change what my query does?
No. GraphQL is whitespace-insensitive and commas are treated as insignificant, so re-indenting selection sets, breaking long argument lists and dropping redundant commas cannot change the document's meaning. The formatter re-prints from a parsed structure rather than rearranging your raw text, and it preserves string and block-string literals byte-for-byte — the parts where whitespace does mean something. Comments are kept too, printed on their own line above the item they preceded.
Is this a full GraphQL validator?
No, and the page says so plainly: this is a structural formatter. It parses the document's grammar — operations, fragments, selection sets, arguments, directives, variable definitions and the schema-definition family (type, interface, input, enum, union, scalar, schema, directive, extend) — and reports syntax errors with line and column. It does not check the document against a schema: unknown fields, wrong argument types and undeclared variables pass here, because judging them requires your schema, which never leaves your own tooling.
When do argument lists break across lines?
When they outgrow the line: argument groups (and variable definitions) that render within 88 characters stay on one line like `user(id: ID!, q: String)`; longer ones break with one argument per line, indented, closing parenthesis on its own line — the same shape Prettier-style formatters produce, so output diffs cleanly against code formatted elsewhere. Selection sets always expand one field per line; scalar definitions like unions stay on one line by design.
What errors does it catch, and how precisely?
Lexer and grammar errors: an unterminated string (reported at its opening quote), an illegal character, a selection set left unclosed (reported, with the line it opened on), an empty selection set, a fragment missing its type condition, a variable definition missing its type, stray closing braces. Each message ends with a line and column. What it cannot catch is semantics — a field the schema does not have is grammatically perfect GraphQL and formats fine; see the validator question above.
Why does my document come back without commas between arguments?
Because in GraphQL commas are officially insignificant — the specification treats them as ignored tokens, like whitespace. The formatter keeps commas that separate arguments and list values in the conventional places, and drops the odd trailing or doubled comma, which is harmless: every conforming parser reads both spellings identically. If a diff tool shows comma-only noise on the first format, that first pass is the normalisation; subsequent formats are stable.
Dev