JSON vs Markdown SERPs: we measured tokens
When an agent calls a search tool, the whole response lands in the model's context. You pay for every token, and the model has to read past every one of them to find the three links that matter. So the format of a SERP r
When an agent calls a search tool, the whole response lands in the model's context. You pay for every token, and the model has to read past every one of them to find the three links that matter. So the format of a SERP response is not a detail: it is a cost line and a quality lever.
We took one Google results page and rendered it three ways.
These are estimates on a single sample, not a benchmark. The sample is an abridged results page (an answer box, three organic results, two People Also Ask questions, three related searches). Tokens are estimated at about 4 characters per token. Real pages are bigger and real tokenizers differ. The ratios are what to take away.
The results
| Format | Estimated tokens | vs pretty JSON |
|---|---|---|
| JSON, pretty-printed | 668 | baseline |
| JSON, minified | 534 | -20% |
| compact JSON | 248 | -63% |
| Markdown | 240 | -64% |
On this sample, Markdown is about 64% smaller than pretty JSON, and compact JSON about 63%. That is in line with the 60-80% reduction we see on full pages. For scale: a full, unfiltered Google SERP as JSON can reach roughly 24,700 tokens once every widget, sitelink and thumbnail is included. At that size the format choice is the difference between a cheap tool call and an expensive one.
Where the tokens go in JSON
Most of a JSON SERP is structure, not content: repeated keys ("position", "title", "link", "snippet"), quotes, braces, indentation, and fields the model never uses (the request echo, metadata, sitelinks, thumbnails). Minifying helps with whitespace but keeps every key.
Compact: JSON for tools
Compact JSON keeps the structure but shortens keys and drops fields agents rarely read. Use it when a program, not the model, consumes the output, or when your tool schema needs structured fields.
Markdown: text for models
Markdown renders the page as prose with numbered links. Models read it the way they read any document, and citations stay attached to URLs:
# best espresso machine 2026
## Results
1. **The Best Espresso Machines of 2026, Tested and Reviewed** β example.com
https://www.example.com/best-espresso-machines
We pulled more than 1,200 shots on 42 machines to find the best espresso makers for every budget.
2. **Espresso Machine Buying Guide (2026)** β coffee.example.org
https://coffee.example.org/guides/espresso
Single boiler, heat exchanger or dual boiler? What the specs mean.
## People also ask
- **What is the #1 rated espresso machine?** Reviewers most often rank dual-boiler machines with PID control at the topβ¦
## Related searches
best espresso machine under $500 Β· best espresso machine for beginners
Going further: project the fields
If your agent only needs titles, links and the knowledge graph, ask for just those:
{ "q": "best espresso machine 2026", "fields": "results.title,results.link,knowledge_graph" }
Log an estimated token count per call (we return it in an X-Tokens-Estimate response header) so you can see what each tool call actually costs you.
What we recommend
- Agent reads the results directly: Markdown.
- Code post-processes the results: compact JSON or field projection.
- You store results or need every field: full JSON.
We built this into SerpKite, a Google SERP API for AI agents, where the three formats cost the same (1 credit per page). You can try them on your own queries in the SERP token counter, and the parameters are in the docs. Whichever API you use, measure your own pages before you pick a format.
Originally published at https://serpkite.com/blog/json-vs-markdown-serp-tokens
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.