GraphQL Formatter

1. Paste a query or schema, open a .graphql or .gql file with ⌘/Ctrl O, or load an example. Formatting runs as soon as the input changes.
2. Set Print width to match your project; it decides whether variable lists and arguments stay on one line or break one per line.
3. Copy the result with ⌥/Alt C, download it with ⌘/Ctrl S, or choose Format JSON variables to move on to the variables object.

#Minified query from a network log

Operations captured from browser dev tools are usually on one line; each selection set gets its own indented block.

query GetUser($id:ID!){user(id:$id){id name email posts(first:5){edges{node{id title publishedAt}}}}}

Result:

query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
    posts(first: 5) {
      edges {
        node {
          id
          title
          publishedAt
        }
      }
    }
  }
}

#Schema SDL with a description and directives

Block descriptions are moved onto their own lines, and directives stay attached to the field they annotate.

# Orders API
"""An order placed by a customer"""
type Order @key(fields:"id"){id:ID! status:OrderStatus! @deprecated(reason:"use state") items:[LineItem!]!}
enum OrderStatus{PENDING PAID SHIPPED}

Result:

# Orders API
"""
An order placed by a customer
"""
type Order @key(fields: "id") {
  id: ID!
  status: OrderStatus! @deprecated(reason: "use state")
  items: [LineItem!]!
}
enum OrderStatus {
  PENDING
  PAID
  SHIPPED
}

#Long variable list

When the operation header is wider than the print width (80 here), each variable definition moves to its own line. At a print width of 120 the same header stays on one line.

query Search($term:String!,$first:Int=20,$after:String,$filters:SearchFilters){search(term:$term,first:$first,after:$after,filters:$filters){totalCount}}

Result:

query Search(
  $term: String!
  $first: Int = 20
  $after: String
  $filters: SearchFilters
) {
  search(term: $term, first: $first, after: $after, filters: $filters) {
    totalCount
  }
}

• Print width — the line length Prettier tries to stay within before it breaks variable definitions, arguments and directive lists across lines (80, 100 or 120).
• Tab width — the number of spaces used for each nested selection set, field list or enum body (2 or 4).

#Syntax Error: Expected Name, found

The document ends before every { is closed, usually because a query was copied partially. Count the braces from the innermost selection outwards, or look at the reported line, which points to the end of the input.

#Syntax Error: Expected Name, found String "query"

You pasted the JSON request body ({"query": "...", "variables": {...}}) rather than the GraphQL document. Copy only the value of the query field, and unescape it first if it contains \n sequences. The variables object belongs in the JSON Formatter.

#Syntax Error: Unterminated string

A string argument is missing its closing double quote. GraphQL strings use double quotes only; single quotes are not valid string delimiters, and multi-line text needs a """ block string.

#Syntax Error: Unexpected "}"

There is one closing brace more than there are opening braces. The column in the message points at the extra brace.

#My commas disappeared

Commas are insignificant in GraphQL, so Prettier drops them between fields and variables and uses line breaks instead. Arguments that fit on one line are separated with , as usual. The meaning of the document does not change.

#Does it format both queries and schemas?

Yes. The same parser accepts executable documents (queries, mutations, subscriptions and fragments) and type-system documents (types, inputs, enums, interfaces, unions, scalars, directives and extend definitions). You can paste a whole .graphql file that mixes several operations and fragments, and each definition is formatted in place without being reordered.

#Is my API schema sent anywhere?

No. Prettier and its GraphQL plugin run in your browser, and the editor sits in an isolated frame that blocks network requests, so nothing is uploaded or stored on a server. Your print width and tab width are remembered on this device; the query itself is only kept if you turn on "Remember my last input".

#Does the formatter validate my query against a schema?

No. It checks that the document is syntactically valid GraphQL and reports the line and column of the first syntax error. It does not know your schema, so unknown fields, wrong argument types or missing required variables are not reported. Your GraphQL server or a schema-aware client will catch those.

#Why are there no blank lines between my types?

Prettier keeps blank lines you already have (collapsing several into one) but does not insert new ones. A minified schema therefore comes out with definitions directly after each other. Add a blank line between definitions once and it will be preserved on every later format.

#Are comments preserved?

Yes. # comments stay where they are, attached to the next definition or field. Descriptions are kept and moved onto their own line above the definition; """ block descriptions are expanded over three lines, while single-line "description" strings keep their quote style. Neither comments nor descriptions are reflowed.

#How do I format the variables that go with a query?

Variables are plain JSON, not GraphQL. Choose Format JSON variables after formatting, or paste them into the JSON Formatter directly. If your client code embeds the query in a template literal, the JavaScript Formatter or TypeScript Formatter handles the surrounding code.

Prettier's output matches what most GraphQL tooling produces: two-space indentation, one field per line inside a selection set, a space after each colon, and arguments kept inline until they exceed the print width. Keeping queries in this shape makes diffs smaller, because adding a field changes exactly one line. The same Prettier defaults apply across the other code formatters in the code tools; Prettier defaults explained covers the reasoning behind print width and indentation.