Use the free GraphQL Query Formatter below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
Why GraphQL Queries Get Messy
GraphQL queries usually start life tidy and end up as a single unreadable line. Someone copies a query from a browser dev tools panel, or a client library logs it without line breaks, or a teammate pastes it into a chat window that strips the formatting. The query still works, but nobody can read it, review it, or spot the extra field that is slowing the response down. Formatting is not decoration here: it is the difference between a query you can reason about and one you can only hope is right.
Unlike JSON, GraphQL has its own grammar with operations, fragments, variables, directives, and nested selection sets. A generic code beautifier that does not understand that grammar will either refuse the input or mangle it. That is why this tool uses Prettier with its GraphQL plugin, the same formatter many teams already run in their editors. It parses the query properly, then prints it with consistent indentation, line breaks, and spacing.
How to Use the Tool
Paste your query into the input box and press Format query. A clean version appears below, with each nested field indented one level deeper and arguments kept readable. Choose a line width if your team uses one: 80 is the default, 100 and 120 are offered for wider screens. If you prefer tabs over spaces, tick the box before formatting. The Copy button puts the formatted query on your clipboard.
If the query has a syntax error, the tool says so and shows the parser’s message instead of guessing. That is genuinely useful: a missing brace or an unclosed parenthesis is much easier to find when the formatter points at it than when you stare at a one-line string. Fix the error, format again, and the clean version appears.
What Good Formatting Reveals
A formatted query makes over-fetching visible. When fields are nested ten levels deep, you can see at a glance that a list page is pulling full author bios and comment threads it never displays. Flattening the indentation in your head is impossible on a one-line query, but a formatted one shows the shape immediately. Reviewers also catch duplicated fields, arguments passed to the wrong level, and fragments that are defined but never used.
Formatting also makes diffs readable. Two versions of a query that differ by one field produce a clean diff when both are formatted, and an incomprehensible one-line change when they are not. If your team stores queries in version control, formatting before committing saves every future reviewer from the same squinting exercise.
Queries, Mutations, and Fragments
The formatter handles the full GraphQL document, not just queries. Mutations format the same way, with their variables and return fields nested cleanly. Fragments keep their definitions and their spreads, so a document that mixes several operations stays organized. Directives like @include and @skip stay attached to the fields they modify, which matters because moving a directive to the wrong line changes what it applies to.
Variables deserve care too. A query with a long variable list formats its variable definitions across lines when they exceed the width, keeping each variable and its type readable. Default values stay with their variables. If you use the formatted query in code, remember that formatting never changes the query’s meaning: it only changes whitespace, so the server receives the same request.
Formatting Versus Minifying
People sometimes confuse formatting with minifying. Minifying strips all unnecessary whitespace to shrink a query for transport, which is what a production client should send. Formatting does the opposite: it adds whitespace to make the query readable for humans. Use the formatted version while writing, reviewing, and debugging, and let your client library minify at runtime if it does. Never debug a production issue from a minified query when a formatted copy exists.
One more distinction: formatting does not validate your schema. A query can be perfectly formatted and still ask for a field that does not exist, or pass a variable of the wrong type. Schema validation happens in your editor plugin, your codegen step, or your server’s error response. The formatter’s job is narrower: it guarantees the syntax is valid and the layout is consistent.
Building a Formatting Habit
The cheapest way to keep queries readable is to format on save in your editor, using the same Prettier setup this tool uses. Then pasted queries from logs or network panels become the exception, and this tool covers those: paste, format, copy back. Teams that adopt one line width and one indent style stop arguing about layout in reviews and start reviewing what the query actually asks for.
If you maintain documentation with example queries, format those too. Readers copy examples constantly, and a formatted example teaches the shape of the query while an unformatted one teaches nothing. A few seconds of formatting pays off every time someone reads, reviews, or reuses the query.
Pingback: Formatear Consultas GraphQL Gratis - Ordena tu Query GraphQL