Gera Tools

Structured Output Token Overhead Calculator

See how JSON mode or structured outputs inflate token costs

JSON schemas, forced formatting, and structured outputs add tokens. This tool estimates the overhead for your schema and response shape versus freeform text, so you can budget the real cost of JSON mode. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Why does JSON mode cost more?

Every key, quote, brace, comma and bracket is itself tokens the model must generate. A field like "customer_name": "Jane" spends tokens on the key and punctuation on top of the value, so the same information costs more in JSON than in prose.

Structured output token overhead calculator

Forcing a model to return strict JSON, a fixed schema, or tool-call arguments is convenient — but every brace, quote, key and comma is output tokens the model has to generate and you have to pay for. This tool estimates how much extra you spend by demanding structured output versus letting the model answer in plain prose.

How it works

Output billing is per token, and structural characters are not free. Consider a single field:

"customer_name": "Jane Doe"

The value is Jane Doe, but you also pay for the key customer_name, two pairs of quotes, a colon and the surrounding braces and commas. Across a deeply nested schema with many keys, this “syntax tax” can add 20–60% to the output token count. The calculator counts the non-value (structural) characters in the schema you paste, converts them to tokens at roughly 4 characters per token, and compares the full JSON token count against the freeform baseline you provide.

Where the overhead actually comes from

Not all structured output is equally expensive. Understanding the sources helps you minimize cost without sacrificing structure:

Keys are paid on every record. In an array of 1,000 records, the key "customer_identifier" (22 characters) appears 1,000 times. That single verbose key name consumes roughly 5,500 extra characters versus a short alternative like "id" (4 characters) — a difference of more than 1,300 tokens across the array.

Pretty-printing adds significant whitespace. A schema with newlines and two-space indentation may use 30–50% more characters than minified JSON conveying identical information. In production there is almost never a reason to send pretty JSON to a model.

Nested objects multiply the cost. Each level of nesting adds braces, and every nested key repeats on every record. A flat array of values is always cheaper than a nested object hierarchy that encodes the same data.

Worked example

For example: a schema producing {"invoice_number": "INV-001", "total": 150.00, "paid": true} per record has roughly 60 structural characters (keys, braces, quotes, punctuation) versus about 16 value characters. The same data in prose — “Invoice INV-001 for £150, paid” — is about 30 characters total. The JSON approach uses roughly twice the tokens for output. At high volume this compounds quickly.

Tips to cut structured-output cost

  • Use short, flat keys (id not customer_identifier) — keys repeat on every record and add up fast in arrays.
  • Avoid pretty-printing in production; request minified JSON with no extra whitespace or newlines.
  • For long lists, consider returning CSV or newline-delimited values when a strict schema is not required — far less punctuation per row.
  • Cache the prompt/schema where the provider supports prompt caching so the input side of the schema is cheaper, even though the output side still costs.
  • When the schema is a single top-level array, wrap the array in an object key (e.g., {"items": [...]}) only if your code requires it — skipping the wrapper saves a small but real token count per call.