GraphQL Prettier - format and validate queries in your browser
A GraphQL formatter takes a document that arrived as one unreadable line - minified for the wire, copied out of a DevTools network tab, or pulled from a server log - and prints it again with proper indentation. This one parses the text into a real syntax tree with graphql-js, the reference implementation, and prints that tree from scratch, so the layout follows the document structure instead of a brace count. Nothing is uploaded.
Why formatting GraphQL is safe
Whitespace and commas are insignificant in GraphQL. The grammar treats spaces, newlines, tabs and commas as ignored tokens, which is why query Hero($ep:Episode!){hero(episode:$ep){name}} and the same query spread over eight indented lines are the identical request. A server cannot tell them apart. That is what makes pretty-printing a free operation: re-indenting a query can never change what it asks for, so you can reformat anything before reading it.
It also explains why minify mode is worth having. Stripping every ignored character produces the smallest payload that still means the same thing, which matters when a query has to travel in a URL or a constrained request body. The tool reports the byte saving both ways.
Executable documents versus SDL
GraphQL has two document flavours and the tool detects which one you pasted. An executable document holds the query, mutation and subscription operations a client sends, along with the fragment definitions they reuse. A Schema Definition Language document describes the API itself - type, input, interface, union, enum, scalar, directive and extend definitions, usually with """docstring""" descriptions attached. Reading a large introspected schema dump is far easier once each type sits on its own indented block.
Un-escaping a captured network payload
A query copied from a browser network tab is rarely plain GraphQL. It arrives wrapped in a JSON request body, with its newlines flattened into literal \n sequences and its quotes escaped. Paste the whole body and the query string is lifted out, decoded and formatted, while the variables object is pretty-printed alongside it.
\\n means a backslash followed by an n, not a newline - is therefore never quietly rewritten.Syntax errors, with a line and a column
When a document fails to parse you get the parser's own message, the exact line and column, and a caret frame pointing at the token that stopped it. Unbalanced braces, an unterminated string, a missing type after on and an empty selection set are all reported precisely, which beats a vague server-side rejection. Beyond syntax, the tool flags what it can see structurally: duplicate operation or fragment names, an anonymous operation sharing a document with others, undefined fragment spreads, unused fragments, and variables used without being declared.
Depth, field counts and query cost
The statistics panel counts operations, fragments, field selections, declared variables and directive usages, and reports the maximum nesting depth. Depth is the usual proxy for what a query costs a server, because each extra level can multiply the number of resolvers that run. Many production APIs reject queries past a depth limit outright, so seeing that number before you ship a query is useful.
The options that rewrite the document
Plain formatting only moves whitespace. Two options genuinely change the document and are off by default: sorting fields alphabetically, which is observable because a response lists its keys in query order, and removing duplicate fragments, which drops definitions. Both re-parse their result and compare it against the original before it is shown.
# comments do not exist in the GraphQL syntax tree, so any option that rewrites the tree - sorting fields or types, moving fragments, stripping descriptions - has to drop them. Ordinary formatting keeps them, and you are told whenever a pass removed one.Syntax checking is not schema validation
This page validates syntax, not types. It proves a document is well-formed GraphQL and points at structural problems it can see on its own, but confirming that a field exists, that an argument has the right type or that a fragment's type condition is valid needs your server's schema - which this tool never sees, by design.