ModernCalcs

GraphQL Variables Formatter

Format and validate the JSON variables object you'd send alongside a GraphQL operation.

{
  "id": "user_123",
  "input": {
    "name": "Jane Doe",
    "email": "jane@example.com",
    "tags": [
      "admin",
      "beta"
    ]
  },
  "limit": 10,
  "includeDrafts": false
}
Valid variables object. Reference in your query as: $id$input$limit$includeDrafts

GraphQL Variables Formatter: Get the Shape Right

GraphQL requests separate the query text from its variables, sent as a JSON object in the request body. This tool formats that variables object for readability and, more importantly, checks that it's structurally valid for GraphQL — specifically, that the top level is an object rather than an array or bare value, which is the most common mistake when hand-writing a request payload.

Formula
GraphQL request body: { 'query': '...', 'variables': { $key: value, ... } }

The variables field must be a JSON object — each top-level key corresponds to a $variableName reference in the query text.

Why the Top Level Must Be an Object

The GraphQL-over-HTTP convention (used by virtually every GraphQL server) expects `variables` to map variable names to values as a JSON object. Sending an array or a bare string there doesn't correspond to any variable — this is a subtle mistake that produces a server-side error that doesn't always clearly say 'your variables shape is wrong.'

Connecting Variables to Your Query

A variables object like `{ "id": "abc" }` supplies the value for a `$id` reference declared in your operation signature — `query GetUser($id: ID!) { user(id: $id) { name } }`. This tool lists out the `$name` references your current variables object would provide, as a sanity check against your query's declared variables.

Practical Examples

Preparing a Mutation Payload

Formatting nested input variables for a mutation.

  • 1.Paste the raw variables JSON
  • 2.Get pretty-printed, valid JSON
  • 3.See the $variableName references it provides

What Gets Checked

  • Valid JSON syntax
  • Top-level value is an object (not array/primitive)
  • Lists the $variableName references the object provides

Good Use Cases

  • Formatting a variables payload before pasting into a GraphQL client
  • Double-checking a hand-written variables object is structurally valid
  • Documenting which $variables a saved query expects

Frequently Asked Questions

Why does this require the top level to be a JSON object?

The GraphQL over HTTP spec requires the `variables` field in a request body to be a JSON object mapping variable names to values (e.g. { "id": "123" }) — a top-level array or primitive value isn't valid there, so the tool flags it explicitly rather than silently formatting invalid input.

How do I reference these variables in my query?

Each top-level key becomes a variable reference prefixed with $ — a variables object of { "id": "123" } is referenced in your query as $id, matched against a declared operation variable like query GetUser($id: ID!) { ... }.

Does it validate variable types against my GraphQL schema?

No — this tool only validates that your input is well-formed JSON with an object at the top level. It doesn't have access to your schema or operation definition, so it can't check that a variable's JSON type matches its declared GraphQL type.

Can nested object properties be referenced individually?

No — only top-level keys in the variables object become GraphQL variable references. A nested value like variables.input.name is passed through as part of the $input value; your query would need to declare $input as a whole input-object-typed variable, not reference .name separately.

Is my data sent anywhere?

No, formatting and validation happen entirely in your browser.