GraphQL Query Builder

Write, validate and format GraphQL queries, mutations and subscriptions — with variables, fragments and ready-to-send exports — without leaving your browser.

Paste or compose a GraphQL document and the builder does the legwork: a real parser checks your syntax (with line and column on every error), your variables are tracked against the JSON you send, fragments are cross-referenced, and the depth/field stats tell you what an API’s complexity limits will see. Format with comments preserved, minify for compact payloads, and export copy-ready cURL, fetch() or GET-URL requests.

🔒 100% private — nothing is uploaded or stored. Your queries, variables and endpoint URL are parsed and formatted entirely in this tab. No request is ever sent from this page to any server — the exports below are text for you to copy and run yourself.

1 · Build your operation

Try:

2 · Variables

The JSON object you will send as "variables". Leave it empty for a variable-free query. Missing variables are filled from their declared types with sensible placeholders.

3 · Analysis

4 · Output & export

Formatted query

—

Minified query

—

cURL request

—

JavaScript fetch()

—

GET request URL

—

GET export is only available when every operation in the document is a query.

How GraphQL documents work

  • One endpoint, exact fields. A GraphQL server exposes a single URL (often /graphql). Instead of over-fetching from many REST endpoints, you send a document describing exactly the fields you want, nested to any depth. The response mirrors your query structure one-for-one — which is why the formatted output above is also the shape of the JSON you will get back.
  • Queries vs mutations vs subscriptions. query reads data (safe to repeat, cacheable), mutation writes it (create/update/delete — typically takes an input object), and subscription opens a persistent stream over a WebSocket or SSE connection rather than a plain HTTP POST. That is why the GET/cURL exports here only make sense for queries and mutations.
  • Variables keep requests cache-friendly. Hard-coding values (owner: "octocat") means every different value is a different query string, which defeats server-side query caching. Declaring $owner: String! in the signature and passing it in the "variables" JSON keeps the query text constant while the data changes — and the type check happens before your request ever reaches the network. The analysis panel above flags variables that are used but undeclared (a guaranteed rejection) and declared-but-unused ones.
  • Fragments remove duplication. A named fragment (fragment repoIssues on Repository { ... }) is reused with a spread (...repoIssues) anywhere the type matches; an inline fragment (... on Comment { body }) narrows a union or interface to one concrete type. The builder cross-references both: undefined spreads are errors, unused fragments are flagged.
  • Depth and complexity are real costs. Every nested field can fan out into database work, so most production GraphQL APIs cap query depth (often 5–8 levels) or charge a complexity score per field. The stats panel reports your document’s max depth and total field count so you can see where you stand before the server tells you.

Once you have a request ready, the API Request Builder helps you assemble and inspect the full HTTP request, the cURL to Code Converter turns the export into Python/Go/Ruby and more, and the JSON Formatter & Validator tidies the response when it comes back.


Luke Keam
Spot a bug or want a custom utility built? I'd love to hear from you. Get in touch
Luke Keam | techgeek.biz