GraphQL Formatter

Beautify any GraphQL in one paste.

Free online GraphQL pretty-printer for queries, mutations, fragments, and schemas. Indents by depth, preserves comments and block strings, validates brace balance — and scores a schema's documentation completeness.

2 or 4 spaceBrace balance checkSchema doc score

GraphQL input

Paste a query, mutation, fragment, or full SDL schema. Strings and comments are preserved.

11 lines·390 chars
Braces and parens balance — looks structurally valid.
Formatted GraphQLgraphql
query GetUser($id: ID!, $includePosts: Boolean = false) {
  user(id: $id) {
    id name email avatarUrl posts(first: 10, orderBy: CREATED_DESC) @include(if: $includePosts) {
      edges {
        node {
          id title publishedAt comments(first: 3) {
            totalCount nodes {
              author {
                id name
              }
              body
            }
          }
        }
      }
      pageInfo {
        hasNextPage endCursor
      }
    }
  }
}
# A reusable fragment
fragment AuthorBits on User {
  id
  name
  avatarUrl
}
Dokly

Documenting a GraphQL API?

Dokly publishes GraphQL schema docs alongside REST and MDX content — search, theming, and AI-ready out of the box.

Try Dokly free →

What this formatter does (and doesn't)

The formatter walks your GraphQL character by character and re-emits it with consistent indentation. It keeps the things you want kept — strings, block strings (""" ... """), and comments (#) — and standardizes the rest: one field per line, two- or four-space indent based on brace depth, argument lists kept inline.

When to use it

  • Cleanup pasted queries: an API consumer dumped a one-liner — paste it here for a readable version.
  • Format a schema: normalize a hand-edited .graphql file before committing.
  • Embed in docs: paste a clean version into your MDX so readers can follow the shape of a request.

What it doesn't do

  • It is not a full GraphQL parser. It won't catch every syntax error — only mismatched braces, parens, and unterminated strings.
  • It does not introspect schemas, run queries, or validate fields against a type system. It's a formatter, not a client.

Schema documentation completeness score

Paste a full SDL schema — not just a query — and a documentation completeness score appears above the output. It checks whether your types have """description""" strings, whether at least half your fields do, and whether every @deprecated field gives a reason. A schema can be valid GraphQL and still tell a reader nothing — this scores the gap.

Privacy

Everything runs in your browser. Your queries and schema never leave your machine.

Frequently asked questions

Does this format queries, or just schemas?
Both. Paste a query, mutation, subscription, fragment, or a full SDL schema (type/interface/enum/input definitions) — the formatter re-indents whatever you give it. The documentation completeness checker below only activates when it detects an actual schema, since a query has nothing to document in the same way.
What does the documentation completeness score check?
Three things GraphQL's own description syntax makes possible: whether most of your types have a description (a `"""block"""` or `"single-line"` string right before `type`/`interface`/`enum`/`input`/`union`), whether at least half your fields do, and whether every `@deprecated` field gives a `reason`. A schema can be perfectly valid GraphQL and score 0 here — validity and documentation quality are different things.
My schema has no deprecated fields — does that hurt the score?
No. The deprecation check only looks at fields that actually use `@deprecated`; a schema with none isn't penalized for having nothing to explain. Same logic as the parameter-description check on the OpenAPI completeness checker.
Does this tool send my schema anywhere?
No. Formatting and scoring both happen in your browser — your query or schema never leaves your machine. That also means it works fine on a schema with private type or field names.
Why does GraphQL use triple-quoted strings for descriptions?
The GraphQL spec reserves a bare `"string"` or block `"""string"""` immediately before a definition as its description — introspection tools (GraphiQL, Apollo Studio, GraphQL Code Generator) read it and show it as documentation. It's the same role a JSDoc comment plays for a function, except it's part of the schema itself rather than a comment the parser ignores.
Can the checker tell a description from a default value?
Yes, by position: a description always stands alone right after `{`, `}`, or the start of the file, while a default value or directive argument always follows `:`, `=`, or a comma inside parentheses. `greet(name: String = "World")` is correctly read as a default, not a description.
Is this a full GraphQL parser?
No — same caveat as the formatter itself. It won't catch every syntax edge case, and a directive argument or description split across unusual line breaks can be missed. For the common case — one field and its description per line, which is how most real schemas are written — it scores accurately.