GraphQL Formatter Online — Format GraphQL Schema

Beautify GraphQL SDL schemas, queries, mutations, subscriptions, and fragments with 2-space indentation and consistent field alignment — 100% in your browser.

Input GraphQL

Formatted Output

What is a GraphQL Formatter?

A GraphQL formatter takes SDL schemas, queries, mutations, subscriptions, and fragments and re-emits them with consistent 2-space indentation, one field per line, and aligned selection sets. It is the same convention applied by graphql-js print() and Prettier's GraphQL plugin — and it is the only way to make introspection results, single-line API responses, or codegen output readable.

Formatting GraphQL is purely cosmetic: the document is parsed to an AST and re-printed, so every formatted version produces an identical AST when re-parsed. The OpenFormatter GraphQL formatter runs entirely in your browser — no schema upload, no API call, no rate limits — making it safe for internal SDL files and federation subgraphs.

How to format GraphQL — 4 steps

Paste your GraphQL. Copy an SDL schema, query, mutation, or fragment into the Input panel. Click Load Sample to try a demo schema.
Click Format. The formatter parses and re-emits the document with 2-space indentation client-side.
Review the output. The Output panel shows the beautified GraphQL ready for your schema.graphql file or query module.
Copy the result. Click Copy to paste the formatted GraphQL into your editor, code review, or documentation.

Side-by-side: condensed vs formatted GraphQL

Condensed

type User{id:ID!name:String!email:String!}type Query{user(id:ID!):User}

Formatted (SDL)

type User {
  id: ID!
  name: String!
  email: String!
}

type Query {
  user(id: ID!): User
}

SDL and Operations

Formats schema definition language (type, interface, union, enum, input) and executable documents (queries, mutations, subscriptions, fragments).

AST Identical

Reformatting only adjusts whitespace. Parsing the formatted version produces the same AST — execution semantics are preserved.

Client-Side Only

Schemas and queries with internal type names or federation entity keys never leave your browser. Verify in DevTools → Network.

Common use cases

check_circleBeautify the result of an introspection query (single-line JSON-encoded SDL)
check_circleFormat GraphQL queries embedded in JavaScript or TypeScript template literals
check_circleReformat SDL exported from Apollo Studio, Hasura, or PostGraphile
check_circleNormalise schema files across a federated graph before commit
check_circleFormat mutations copied from Postman, Insomnia, or GraphQL Playground
check_circleBeautify subscription documents for documentation
check_circleReformat fragments for code review and reuse
check_circleClean up GraphQL output from a code-generation tool (graphql-codegen)

Online formatter vs Prettier vs graphql-js print()

An online formatter is the fastest way to format a single document — paste, click, copy. Prettier with the graphql plugin is the right tool for project-wide enforcement: it integrates with your editor, CI, and pre-commit hook so every .graphql file is formatted consistently. graphql-js print() is the underlying primitive used by both — it parses to AST and re-emits canonical SDL. Use the online tool for one-off snippets; use Prettier for repository-level discipline.

More than formatting

Format JSON, validate JSON Schema, and convert between data formats — all browser-side.

JSON Formatter JSON Validator TypeScript Formatter

Frequently Asked Questions

What is GraphQL SDL formatting?

SDL (Schema Definition Language) is the canonical text representation of a GraphQL schema. Formatting SDL means putting each type, field, and argument on its own line with consistent 2-space indentation, descriptions immediately above their target, and directives in a deterministic order. The graphql-js print() function and Prettier with the graphql plugin both apply this convention.

Does formatting GraphQL change query semantics?

No. GraphQL is whitespace-insensitive (outside of block string descriptions). Reformatted queries, mutations, and fragments produce identical results when executed. The AST that graphql-js parses is unchanged.

How are descriptions formatted in SDL?

Descriptions use block strings (""" ... """) immediately above the type, field, or argument they describe — no blank line between. Single-line descriptions can use """short""" on one line. The June 2018 spec deprecated # comments for documentation; tooling (Apollo, GraphiQL, GraphQL Playground) only renders block-string descriptions.

In what order should directives appear?

Directives apply in the order written and most printers emit them in source order. Common conventions: @deprecated last (it is metadata about the field state); auth/access directives first (@auth, @hasRole); then transformation directives (@formatDate, @upper). Apollo Federation directives (@key, @external, @requires) are emitted in spec order.

Can it format both schema and operation documents?

Yes. SDL files (schema.graphql) with type, interface, union, enum, input, scalar, directive definitions and executable documents (queries, mutations, subscriptions, fragments) are both formatted. The output uses 2-space indentation and one field per line.

How are long argument lists wrapped?

When a field has multiple arguments, idiomatic GraphQL wraps them onto separate lines: each argument on its own line, indented one level deeper than the field. graphql-js print() and Prettier both apply this when the inline form exceeds 80 characters. Arguments with default values are kept on the same line as the argument name.

Is the GraphQL I paste sent to your servers?

No. Formatting runs entirely in your browser using JavaScript. Schemas containing internal type names, federation entity keys, or operation documents with embedded credentials never leave your device. Open DevTools → Network and click Format to verify.

Does it preserve fragments and inline fragments?

Yes. Named fragments (fragment UserFields on User { ... }), inline fragments (... on Admin { ... }), and fragment spreads (...UserFields) are formatted with the same selection-set indentation as a regular field. Type conditions stay on the same line as the spread.