Compress Web Search Results: 2026 Query-Aware Guide

TL;DR

Compressing web search results means reducing the token count of content returned by web search tools (Tavily, Brave Search API, Exa) before passing it into an LLM’s context window. Raw search output is full of boilerplate, navigation text, and irrelevant content that wastes tokens, inflates costs, and actually degrades answer quality. Query-aware compression keeps only the information relevant to the user’s question, cutting tokens by 46–91% while often improving accuracy.

Quick Takeaway: What is Query-Aware Web Search Compression?

Query-aware web search compression is a prompt-engineering and pre-processing technique that filters raw web search API outputs (e.g., Tavily, Brave, Exa) before injecting them into an LLM context window. By stripping boilerplate, navigation menus, and contextually irrelevant text based on the specific user query, it reduces token usage by 46% to 91% while mitigating the "lost in the middle" accuracy drop in large language models.

Average Token Count: Drops from 2,000 – 27,000+ tokens (Raw) down to 200 – 1,500 tokens (Compressed).
Information Density: Shifts from Low (includes headers, ads, UI noise) to High (only query-relevant passages).
LLM Accuracy Impact: Shifts from Lower (suffers from context degradation) to Higher (preserves signal-to-noise ratio).
API Cost Impact: Reduces overall API spend by up to 90% per tool turn.

What Does It Mean to Compress Web Search Results?

When an AI agent searches the web, the search tool returns content: snippets, extracted page text, metadata, sometimes full Markdown conversions of entire web pages. That content gets injected into the LLM’s prompt alongside system instructions, chat history, tool definitions, and other context.

Compressing web search results is the process of shrinking that search output, removing irrelevant text, boilerplate, and noise, before it reaches the model. The goal is straightforward: preserve the information the LLM actually needs to answer the question while discarding everything else.

This is a specific form of context compression focused on one of the most bloated input sources in modern agent systems: web search tool output.

Try it live in the interactive demo.

Why Web Search Results Need Compression

The token bloat problem

A single web search tool call can easily return thousands of tokens. Raw HTML, cookie consent banners, sidebar navigation, footer links, repeated boilerplate across multiple results. It adds up fast.

The numbers tell the story. One practitioner reported that a single customer support agent burned $340 per month in OpenAI API credits because every conversation round-trip stuffed 80,000 tokens into the prompt window, but only about 12,000 tokens contained actually useful information. A real bug report on the Continue IDE GitHub shows the problem breaking things outright: a web search tool call consumed roughly 27,543 tokens in an agent with only an 8,192-token context window, making it impossible to even include the system message and leave room for output.

Brave’s engineering blog describes what they call the “Markdown Tax,” where search tools that convert pages to Markdown inadvertently pull in junk data like navigation menus and cookie notices, consuming tokens that serve no purpose in the LLM prompt. Every tool call appends results, every conversation turn adds to the running total, and every workflow step leaves a trace. Agent context bloats over time in ways that are hard to predict and expensive to ignore.

Compression improves accuracy, not just cost

Here’s the counterintuitive part: sending less data to the model can produce better answers.

Research from Stanford and the University of Washington demonstrates that LLMs exhibit a U-shaped performance curve when processing long contexts. Models achieve highest accuracy when relevant information appears at the beginning or end of the input, but performance degrades by more than 30% when critical information sits in the middle. This is known as the “lost in the middle” problem.

Even more striking, Du et al. (2025) proved that context length alone degrades performance independent of retrieval quality. Even when irrelevant tokens were replaced with whitespace and models were forced to attend only to relevant tokens, performance still dropped 13.9% to 85% as input length increased.

This means compressing web search results before they enter the prompt is not just a cost optimization. It’s an accuracy optimization. By removing noise and keeping the context tight, you avoid the lost-in-the-middle effect and give the model a better signal-to-noise ratio. For a deeper look at how wasted context hurts output quality, see this guide on wasted LLM context.

The context budget squeeze

Search results don’t exist in isolation inside a prompt. They compete for space with system prompts, chat history, tool definitions, and other retrieved content. As one practitioner on Dev.to put it: “Send too little context, and your agent gives generic, unhelpful responses. Send too much, and you hit token limits, rack up costs, and slow down responses.”

A production agent guide from sinimite.work frames this well: “The goal of production context compression is not to produce the shortest possible summary. It is to preserve the state an agent needs to continue correctly, safely, and verifiably with as few active tokens as possible.”

Context Compression Approaches Compared

To optimize agent workflows, developers combine multiple compression techniques. Below is a breakdown of common strategies ranked from lowest cost to highest complexity:

Structured Cleanup (Pre-compression)

Mechanics: Strips HTML tags, cookie notices, and redundant JSON metadata.
Token Reduction: 10% to 25%.
Hallucination Risk: Zero.
Best Use Case: Always apply first as an initial pre-processing step.

Extractive (Hard) Compression

Mechanics: Selects verbatim sentences containing target keywords.
Token Reduction: 40% to 70%.
Hallucination Risk: Zero.
Best Use Case: Compliance, legal, or strict factual extraction where word-for-word accuracy is required.

Query-Aware Scoring

Mechanics: Scores text chunks against user query intent and keeps only relevant passages.
Token Reduction: 50% to 90%.
Hallucination Risk: Minimal.
Best Use Case: Web search APIs and multi-step Agentic Tool Loops.

Abstractive Summarization

Mechanics: Uses a smaller LLM to rewrite and condense content.
Token Reduction: 60% to 85%.
Hallucination Risk: Moderate (3.4 to 3.7 out of 5 precision rating).
Best Use Case: Conversational context, chat history, and long-form background reading.

Soft (Embedding) Compression

Mechanics: Encodes text as dense vector prompts directly for the model.
Token Reduction: Variable.
Hallucination Risk: Low.
Best Use Case: Single-model architectural setups (less portable across different LLM providers).

Server-Side vs. Client-Side Search: The Opaque Data Problem

This distinction is critical and rarely discussed.

Provider-native (server-side) search is what happens when OpenAI, Anthropic, or Google’s models search the web internally using their built-in tools. The search results flow directly into the model on the provider’s servers. Developers cannot intercept, inspect, or compress these results. The data is opaque.

Client-side search tools are APIs like Tavily, Brave Search, Firecrawl, or Parallel that developers call directly from their application code. The raw results pass through the application layer as plaintext, making them fully compressible before they reach the LLM.

This means compressing web search results is only possible when you control the search tool call. If you’re relying on a provider’s built-in web search, you’re at the mercy of whatever they return, however bloated it may be.

Some client-side APIs are more compression-friendly than others. Firecrawl’s default search response returns ranked, LLM-ready passages that cut input tokens by roughly 10x compared to processing entire result pages. Tavily offers an include_raw_content=True flag that returns extracted page text without HTML, ads, or navigation. Parallel Search returns compressed excerpts optimized for context windows. But even these “AI-optimized” APIs still return more tokens than necessary for a specific query. The search tool optimizes for general relevance. Query-aware compression optimizes for the exact question.

Compare compression tool options.

When to Compress (and When to Skip)

Not every search result needs compression. Here are practical guidelines:

Compress when:

Individual search results exceed roughly 500 tokens each
You’re concatenating multiple search results into a single prompt (deduplication value is high)
Your agent runs multi-turn conversations where search results accumulate across turns
Token costs are a material concern (they almost always are at scale)

Skip compression when:

Search results are already very short snippets (under 200 tokens), where the API overhead outweighs the savings
You’re using a search API that already returns tightly scoped, pre-compressed excerpts and the results fit comfortably within your context budget
The task requires the LLM to see every word of the original source (rare, but possible in legal or compliance scenarios)

The Agno framework documentation captures the sweet spot: the best use case is “agents with tools that return verbose results (web search, APIs)” and “multi-step workflows with many tool calls.”

For teams building agents that call web search tools, Compresr offers client-side search tools for Tavily and Brave with automatic compression at $0.10 per 1M tokens.

Putting It All Together

Compressing web search results sits at the intersection of two trends: the explosion of AI agents that use web search as a core tool, and the growing recognition that prompt compression is not optional at scale. The CRAG research paper demonstrated 46–91% fewer tokens compared to standard RAG pipelines, with maintained or improved answer quality.

The practical takeaway is simple. If your agent calls web search tools, raw results are almost certainly bloating your prompts, inflating your costs, and hurting your accuracy. Structured cleanup catches the obvious waste. Query-aware compression catches the rest by keeping only what matters for the question at hand.

The agents that perform best in production are not the ones with the biggest context windows. They’re the ones that fill those windows with the right information.

Get started with $10 in free credits, no card required.

4-Step Implementation Process

Intercept Search API Response (Client-Side Tool Call): Capture the raw output (HTML or JSON) from your client-side search provider (Tavily, Brave, Exa, Firecrawl) within your application code before sending it to the model.
Execute Structural Cleanup (Pre-processing): Strip structural boilerplate: remove HTML tags, navigation, cookie consent strings, footers, and redundant JSON payload key-value pairs.
Chunk & Score via Query Relevance (Filtering): Break search output into passages (100 to 200 words) and score each against the user's specific prompt turn using a lightweight cross-encoder or semantic reranker.
Inject Top Chunks into Prompt Window: Assemble the top-ranked passages into the LLM system/user context, ensuring primary context sits at the head or tail of the context window to prevent position degradation.

Frequently Asked Questions

What is the difference between compressing web search results and general prompt compression?

General prompt compression applies to any LLM input: system prompts, chat history, documents, tool outputs. Compressing web search results is a specific application focused on the content returned by search APIs (Tavily, Brave, Firecrawl). The techniques overlap, but web search compression also involves unique steps like stripping HTML boilerplate, removing navigation elements, and deduplicating overlapping snippets across multiple search results.

Can I compress search results from ChatGPT or Claude’s built-in web search?

No. When OpenAI, Anthropic, or Google models use their built-in web search tools, the results flow directly into the model on the provider’s servers. Developers cannot intercept or compress this data. You can only compress web search results when using client-side search tools like Tavily or Brave Search API, where the raw results pass through your application code.

How much can I reduce token counts by compressing web search results?

It depends on the source and compression method. Research on CRAG (Corrective RAG) shows 46–91% token reduction compared to standard RAG pipelines. In practice, a single uncompressed search tool call can consume 2,000 to 27,000+ tokens. After query-aware compression, the useful content often fits in a fraction of that, sometimes under 500 tokens.

Does compressing search results hurt answer quality?

When done with query-aware methods, compression typically maintains or improves quality. The “lost in the middle” research shows that long contexts with irrelevant content cause models to miss critical information, with accuracy dropping over 30%. By removing noise, compression gives the model a cleaner signal. Abstractive summarization carries more risk of information loss, which is why extractive and query-aware approaches are preferred.

What is the “Markdown Tax” in web search results?

The Markdown Tax refers to the extra tokens introduced when search tools convert web pages to Markdown format. Cookie consent text, sidebar navigation, footer links, and other page elements get included in the conversion, consuming tokens that add no value to the LLM’s response. This is one reason raw search tool output often needs compression even from APIs that advertise “clean” output.

When is compressing web search results not worth it?

Skip compression when search results are already very short (under roughly 200 tokens per result), when the API overhead of a compression call exceeds the token savings, or when your use case requires the LLM to see every original word verbatim. For most agent workflows with multiple search results or multi-turn conversations, compression pays for itself quickly.

What is context rot and how does it relate to web search compression?

Context rot describes the gradual degradation of context quality as an agent accumulates tool results, messages, and workflow traces over multiple turns. Uncompressed web search results are a primary driver of context rot because each search call appends thousands of tokens, many of which become stale or irrelevant as the conversation progresses. Regular compression of search results helps prevent context rot from building up.