GraphQL Query Formatter
Reformat GraphQL source, preserve lexical meaning, inspect operations and variables, and build JSON or cURL requests.
Paste a query, mutation, subscription, fragment, or copied request body query string.
Request Context
Optional values used when generating request payloads or cURL output.
Leave empty when the query does not need variables.
Used only for cURL output. The placeholder is not sent unless you generate a cURL example without an endpoint.
Needed to build an executable request when the document contains more than one operation.
Options
The formatter is designed for practical readability and request debugging. It does not execute your query.
Output
Formatted GraphQL output will appear here.
Formatting GraphQL safely starts at lexical boundaries
GraphQL allows whitespace, line terminators, commas, comments, and a Unicode BOM as ignored tokens between lexical tokens. That gives a formatter room to change layout, but not permission to rewrite characters that belong inside a string, block string, name, number, or other token.
The formatting path here keeps quoted strings and block strings opaque while it changes surrounding layout. The delimiter check is intentionally narrower than a GraphQL parser: balanced braces can catch a damaged paste, but balanced braces alone do not make a document valid GraphQL.
A preserved comment needs its line ending
GraphQL comments begin with # and continue only to the next line terminator. Removing that terminator while keeping the comment would turn following GraphQL source into comment text. When comments are retained, the formatter and minifier therefore keep the comment boundary intact and ignore braces or parentheses that appear inside the comment itself.
When “Remove comments” is selected, comment text is dropped while a separating line break is retained so neighboring tokens are not accidentally joined.
One document can carry several operations
A GraphQL document may contain multiple query, mutation, or subscription operations alongside reusable fragments. Formatting all of them is fine. Building one executable HTTP request is different: when more than one operation is present, the request needs an operationName that selects the operation the server should execute.
The operation and fragment lists shown above are text-level inspection aids. They are useful for reviewing a copied document, but they do not replace parsing and validation against the schema that will execute it.
Variables are JSON; the GraphQL document is not
Variables travel separately from the GraphQL source and, in the common JSON request format, must be represented by a JSON object. A variable referenced in the document can legitimately be absent from that object when the variable is nullable or has a default, so a missing key is reported as context rather than a syntax error.
GET is not a smaller version of POST
The current GraphQL-over-HTTP draft requires POST support and places GET request parameters in the URL query component. A mutation must not be executed with GET. The cURL output follows those rules: POST uses a JSON body, while GET serializes query, operationName, and variables into the URL when present.
Long GraphQL documents can also make GET URLs impractical or exceed intermediary limits. Server documentation still matters because the GraphQL-over-HTTP transport document linked below is a draft and implementations can have additional constraints.
Formatting stops before schema validation and execution
Field existence, argument types, fragment type conditions, directive placement, variable compatibility, authorization, resolver behavior, query cost, and execution errors all require knowledge this page does not have. A cleanly formatted document can still be invalid for a particular schema.
The GraphQL specification defines the language, document model, validation, and execution rules. HTTP request examples follow the current GraphQL-over-HTTP draft rather than treating transport behavior as part of the core language specification.