Skip to content
ZeroServer.tools

GraphQL Formatter

Format, beautify, and minify GraphQL queries, mutations, and schemas with custom indentation.

Load Preset:
Indentation:

Input Size

197 B

Formatted

251 B

Total Lines

12

Max Depth

5 levels

How GraphQL formatting works

This browser-based GraphQL formatter tokenizes GraphQL operations and schemas, parsing field selections, arguments, and directives while respecting block indentation levels. It handles multi-line arguments, nested fragments, and inline object inputs safely without sending data to an external API.

Need to analyze JSON responses? Try our JSON Formatter or inspect document payloads using JSON Size Analyzer.

Built and maintained by Meet Shah · Last updated

What this tool is used for

  • Making a long query readable before reviewing it.
  • Normalising indentation on a schema several people have edited.
  • Reading a query pasted from a network panel with no line breaks.
  • Checking the real nesting of a deeply selected query.
  • Preparing a query for documentation or a bug report.

Frequently Asked Questions

What does query depth tell me?
How many levels of nesting the query requests, which is the standard proxy for how expensive it is. A deeply nested query can multiply out into an enormous number of resolver calls, and depth limiting is the usual first defence on a public GraphQL endpoint.
Why does GraphQL need a formatter when whitespace is insignificant?
For the same reason JSON does: machines emit it minified and humans read it indented. A query logged by a client or pasted from a network trace arrives as one line, and the nesting — which is the whole structure of what was asked for — is invisible until it is indented.
What is a fragment for?
Reusing a field selection across queries. `fragment UserFields on User { ... }` is declared once and spread with `...UserFields` wherever those fields are needed, so adding a field to the fragment updates every query that uses it. It is the one real abstraction the query language has.
What do @include and @skip do?
Conditionally include a field based on a variable, evaluated by the server — `posts @include(if: $withPosts)`. That is how one query serves two shapes of screen without branching in client code or issuing a second request for the extra data.
Should I minify a query before sending it?
It saves a little bandwidth and costs readability in every log and trace afterwards. The larger win is persisted queries: register the document once, send a hash at runtime. That removes the payload entirely and lets the server reject anything it has not seen before.

Common errors and gotchas

  • Expecting it to validate, since a query can format perfectly and reference a field that does not exist.
  • Reformatting a query with variables and losing the operation name they belong to.
  • Assuming formatting changes the request, when the server sees the same document either way.
  • Losing comments in a schema, which some formatters drop.
  • Formatting a query the client will minify anyway, then committing the expanded form by mistake.

Related Developer Utilities tools

Private & free — this tool runs entirely in your browser.

IndieKitShip your Next.js startup in days.affiliate