Theme

GraphQL Syntax Validator

Paste a GraphQL operation or schema to check that it parses. Errors show the line and column with the message the reference GraphQL parser would give.

Input

Settings

History

Load from URL

What makes a GraphQL document invalid

GraphQL documents are small, but a single unbalanced brace in a deeply nested selection set is easy to miss, and servers respond with a terse 400. The checker parses the document against the GraphQL specification grammar and stops at the first problem. Typical ones:

  • A selection set that is never closed. The parser reaches the end of the document still expecting a field name, which it reports as Expected Name, found <EOF>.
  • Unterminated strings in arguments, such as reason: "duplicate. GraphQL strings cannot span lines unless you use a """block string""".
  • Variable definitions without a colon: query GetOrder($id ID!) instead of $id: ID!.
  • Stray braces or parentheses left after deleting a field or an argument.
  • Invalid names, such as a field starting with a digit.

Both executable documents (queries, mutations, subscriptions, fragments) and type-system documents (SDL with type, input, enum, interface, union, scalar, directive and extend) are accepted.

Messages and positions

Formatting goes through Prettier’s GraphQL support, which parses with graphql-js, the reference implementation, so the wording matches what Apollo, Yoga and most servers print: Syntax Error: Unexpected "}". or Syntax Error: Expected ":", found Name "ID".. The line and column point at the token where parsing failed, and the editor marks it. The previous valid formatting stays visible in the output pane, dimmed, until the document parses again.

Descriptions in SDL, written as """block strings""" above a type or field, are part of the grammar and parse normally. Variables are a different story: the JSON object you send alongside the query is not GraphQL at all, so check that payload with the JSON validator when a request fails with a variables error rather than a syntax error.

Commas are optional in GraphQL; they are treated like whitespace. So a missing comma between arguments is never an error, while a missing colon or brace always is.

Syntax, not schema validation

Parsing is the first of two checks a GraphQL server runs. The second, validation, compares the operation with the schema: does the order field exist, does it take an id argument, is ID! the right type, are fragment type conditions possible, are all variables used? That needs your schema, which this page does not have, so a query asking for nonexistentField passes here. To validate against a schema, use your server’s introspection in GraphiQL or Apollo Sandbox, or the graphql-inspector CLI in CI.

Operations often carry real customer IDs and tokens in their variables. The check runs inside your browser, so none of that is uploaded. Once valid, the GraphQL formatter lays it out and the GraphQL minifier compacts it for a GET request.

Examples

Selection set left open

Invalid: one closing brace is missing, so the parser hits the end of the document while it still expects a field.

Input
query GetOrder($id: ID!) {
  order(id: $id) {
    id
    status
    items {
      sku
      qty
    }
}
Result
Line 9, column 2: Syntax Error: Expected Name, found <EOF>.
Open this example in the tool

Unterminated string argument

Invalid: the quote after ord_8f2k1 is missing, so the string runs into the next argument and never closes properly.

Input
mutation {
  cancelOrder(id: "ord_8f2k1, reason: "duplicate") {
    id
    status
  }
}
Result
Line 2, column 53: Syntax Error: Unterminated string.
Open this example in the tool

Variable without a colon

Invalid: a variable definition needs a colon between the name and its type.

Input
query GetCustomer($id ID!) {
  customer(id: $id) { name email }
}
Result
Line 1, column 23: Syntax Error: Expected ":", found Name "ID".
Open this example in the tool

Valid schema (SDL)

Type definitions parse just like operations; whether the types are used correctly is up to schema validation.

Input
type Order {
  id: ID!
  status: OrderStatus!
  items: [Item!]!
}

enum OrderStatus { PENDING PAID SHIPPED }

type Item { sku: String! qty: Int! price: Float! }
Output
type Order {
  id: ID!
  status: OrderStatus!
  items: [Item!]!
}

enum OrderStatus {
  PENDING
  PAID
  SHIPPED
}

type Item {
  sku: String!
  qty: Int!
  price: Float!
}
Open this example in the tool

Common errors and how to fix them

ErrorCauseFix
Syntax Error: Expected Name, found <EOF>.A selection set or argument list is still open when the document ends.Add the missing closing brace or parenthesis; count braces from the innermost selection outwards.
Syntax Error: Unterminated string.A string argument is missing its closing quote, or a regular string contains a line break.Close the quote, or use a “”“block string”“” for multi-line text.
Syntax Error: Unexpected "}".There is an extra closing brace, or a field was deleted and left an empty position.Remove the extra brace so every { has exactly one }.
Syntax Error: Expected ":", found Name "ID".A variable definition or argument is missing the colon between name and type or value.Write $id: ID! or id: $id.

Frequently asked questions

Does it validate my query against a schema?

No. It checks syntax only. Field names, argument types and fragment conditions need the schema, which you can check with GraphiQL, Apollo Sandbox or graphql-inspector.

Can I validate a schema file?

Yes. SDL documents with type, input, enum, interface, union, scalar and directive definitions are parsed the same way as operations.

Are commas required between fields or arguments?

No. Commas are insignificant in GraphQL and treated as whitespace, so you can use them or leave them out.

Can several operations be in one document?

Yes, they parse. Servers then require each operation to have a unique name, and anonymous operations must be alone, but that rule belongs to schema validation.

Related tools