Why browser-rendered Fetch output answers more questions with fewer tokens.
Expand Fetch is a new kind of website-to-Markdown API that saves you money and preserves more information at the same time.
Other extraction APIs are HTML-to-Markdown: they convert the raw HTML and drop everything that doesn't survive that conversion — JavaScript-rendered content, app state, layout, and page assets. Expand renders the full website the way a browser does and extracts from there, so the data those tools lose is still there.
We'll explain how this is possible with progressive disclosure and the small language models we trained. The result is a clean document plus hidden JSON from the page that other tools don't consider. Oversized secondary regions go in a separate section we call the Appendix.
The goal is not shorter Markdown at any cost, but higher information density.
More complete, but noisy and token-heavy. Navigation, footers, repeated UI, and raw payloads crowd out the useful answer and inflate the bill.
Cheaper but lossy. Hidden state, links, and source evidence vanish exactly when the agent needs them for the next question.
Useful first, recoverable by reference. Main Markdown and curated State JSON carry the common case; deeper evidence stays one handle away.
A web page is not just the main content. It carries app state, links, sidebars, and unwanted noise like ads and cookie banners. This often leads to choosing between two failure modes.
Keeping everything floods the model with low-signal tokens, costing you money.
Keeping only main content swings the other way. Pruning to the article body is cheap, but it throws away the links to follow next and the app state that was never in the prose.
Expand takes a third path. It intelligently selects what to show first by running small language models over all HTML and internal JSON.
Progressive disclosure is how Expand stays pragmatic without becoming lossy. Main Markdown is the readable default document. State JSON rides along when it is useful and fits. The rest is retrievable as needed.
The fetch output comes in two layers:
Useful content first:
Main Markdown + curated State JSON when useful and when it fits.
References to more:
Appendix, complete original HTML and JSON, and page assets (images, SVGs, etc).Most questions are answered by the first layer and when a question needs content from the Appendix, the agent fetches it in a follow-up call.
Layout-aware Markdown keeps tables, grids, pricing pages, feature comparisons, and icons understandable instead of flattening them into loose paragraphs.
Structured page and app data that answers questions Markdown alone cannot. Part of the working context when it fits; recoverable by reference when it does not.
Navigation, links, sidebars, footers, and secondary regions stay reachable without flooding the main output.
Focused retrieval over captured evidence when the agent needs a targeted follow-up instead of another full page read.
Citations, source blocks, snapshots, screenshots, Playground, and Replay map extracted output back to the page regions it came from.
Expand Fetch uses new methods to preserve information that may have been missed otherwise.
It preserves icons and layouts that make things like pricing tables legible and it returns State JSON which answers questions Markdown alone cannot, especially for data-driven pages. There is a reason most agents currently don't use the internal JSON. It would overwhelm their context windows. So we use a small language model to select just the useful fields and elements.
Expand's snapshotting system records the complete HTML and all page assets. You can see this for yourself in how the Playground is able to replay the page as it originally appeared.
Since page assets such as images are saved, the agent can retrieve them even if the website has been shut down.
The snapshotting enables the citations feature, which is a sourcemap for the extracted web page, mapping Markdown+JSON back to the original so you can verify a claim.
The agent can include a citation in its response to precisely point to the evidence for a claim. Then humans can click on those citations to highlight the source regions in the Playground.
The benefits are:
| Use Expand for | A simpler path may be enough | Use browser automation when |
|---|---|---|
| agent research | simple static articles | the task is a long workflow |
| docs ingestion | already-clean Markdown | the goal is form filling |
| product and pricing pages | a known API exposes the exact data | extraction is secondary to interaction |
JS-rendered pages and anything with important tables, icons, layout, hidden JSON, or evidence needs are where Expand is most useful. When the source is a clean static article or a known API that already returns the exact data, a plain fetch or a simpler converter is fine.
Secondary reading: Output Model, Include Options, Browser Behavior, and Playground & Replay.
| dashboards and app-like pages | source verification does not matter | complex interaction determines the result |
| marketplaces and search/detail pages | the page is already structured for LLMs | the agent must operate the page, not just read it |