application/graphql GraphQL Query Common

What it's for

application/graphql is a non-standard (never formally IANA-registered) MIME type occasionally used to send a raw GraphQL query string directly as an HTTP request body, rather than wrapping it in a JSON envelope. In practice, this approach is the minority pattern — the overwhelming majority of GraphQL APIs and clients (including the official GraphQL over HTTP recommendations) use application/json instead, sending the query, variables, and operation name as fields within a JSON object.

Understanding this type mostly matters for recognizing it when you encounter it in older tooling, specific server implementations that chose to support it, or documentation that references it, rather than as a recommendation to actually use it for new API design.

Format & syntax

Content-Type: application/graphql

query {
  user(id: "123") {
    name
    email
  }
}

The request body is the raw GraphQL query text itself — no JSON wrapper, no separate variables field support in this format (which is a real practical limitation compared to the JSON-based approach, since GraphQL queries commonly need to pass variables alongside the query).

How it's used in practice

• Simple query-only requests without variables — since this format has no standard way to pass separate variables, it's really only practical for GraphQL operations that don't need them, which limits its usefulness for most real-world queries.
• Specific tooling/server support — a small number of GraphQL server implementations and tools support accepting this content type as an alternative input method, mostly as a convenience for simple testing/debugging scenarios rather than production API design.
• Historical/early GraphQL tooling — some earlier GraphQL client and server implementations experimented with this approach before the JSON-based convention became the clear, dominant standard.

Common mistakes & gotchas

• Assuming this is the standard way to call a GraphQL API — the standard, universally supported approach is application/json with the query, variables, and operationName as JSON fields — reaching for application/graphql for a new integration is very likely to hit compatibility issues with the vast majority of GraphQL servers, which expect JSON.
• No native support for query variables — a real practical limitation: this raw-text format has no standard mechanism for passing variables alongside the query, which most non-trivial real-world GraphQL queries need, making this format impractical for anything beyond the simplest static queries.
• Server support is inconsistent — because this was never formally standardized, different GraphQL server implementations vary in whether (and how) they support accepting this content type at all, unlike JSON-based GraphQL requests which are near-universally supported.

Comparison & FAQ

Should I use application/graphql for a new GraphQL integration?

No — use application/json with the query, variables, and operationName as fields in a JSON body. This is the standard, universally supported approach across essentially all GraphQL tooling and servers.

Can I pass variables using application/graphql?

Not in a standardized way — this raw-text format has no built-in mechanism for separate query variables, which is one of the main practical reasons the JSON-based approach became the dominant standard instead.

Why does some older documentation or tooling reference application/graphql?

It reflects an earlier, less-standardized period of GraphQL tooling development before the JSON-based request format became the clear, widely adopted convention across the ecosystem.

Is application/graphql an officially registered MIME type?

No — it was never formally registered with IANA, which is part of why support for it varies inconsistently across different GraphQL server implementations, unlike the universally recognized application/json.