Your agent reads the HTML. It should see the page. What ordinary Markdown APIs drop, and how Expand keeps it.
Your agent reads the HTML. It should see the page. An HTML-to-Markdown converter works from the source and guesses what matters, and the guess is silent. Tables lose their columns, icons vanish, and the JSON a page loads for itself never appears. So the agent gets stuck, or misses the answer, or states something false, and you can't tell which happened. Driving a full browser for every page fixes that, at the cost of speed and money.
Expand takes a different route. You send a URL. Expand opens it in a real browser, and our model Iris looks at the rendered page and returns it whole as Markdown, with layout, tables, and icons intact and the trash removed. The page's hidden JSON comes back next to it as State JSON. Every line links back to the exact spot on the page, so you can check every result at API speed.
HTML-to-Markdown converters decide what counts as content with fixed rules, and the rules fail in three ways. They keep things they shouldn't. They drop things they shouldn't. And some things they cannot see at all. The drops are random and silent, so you never know what your agent didn't see.
| What gets dropped |
|---|
| What your agent sees instead |
|---|
| Example |
|---|
| Table structure | Cells collapse into loose text and values detach from their column headers. | A pricing page. Which plan has which feature can't be recovered. |
| Icons | A checkmark column and a cross column read as identical empty cells. | Any comparison table. Yes and no look the same. |
| Script-tag JSON | Data that never rendered as text does not exist. | A chart page. The whole dataset lives in a script tag. |
| JavaScript-rendered content | An empty application shell. | Any single-page app fetched without a browser. |
Expand renders the full page the way a browser does and reads the rendered result, so the data those tools lose survives. Iris looks at the rendered page and decides what to show first. You get a clean Main Markdown plus the hidden JSON that other tools never look at. Oversized secondary regions, such as navigation and footers, go in a separate section called the Appendix.
The goal is more information per token, not shorter Markdown at any cost.
A web page carries more than its main content. There is app state, links, sidebars, and noise such as ads and cookie banners. Most tools pick one of two failure modes.
Keeping everything floods the model with low-signal tokens, and you pay for every one of them.
Keeping only the 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 looks at the rendered page and the page's internal JSON and selects what to show first. The rest stays one call away.
Progressive disclosure keeps secondary page content available without putting it all in front of your agent. The Main Markdown and State JSON answer most questions. The Appendix, the original HTML and JSON, and the page's assets stay in the Snapshot, one follow-up call away. How your agent goes back for them is on Progressive disclosure.
Expand keeps the icons and layout that make a pricing table legible. It returns State JSON, which answers questions Markdown alone cannot, especially on data-driven pages. Most agents don't read a page's internal JSON today because the whole of it would overwhelm their context window, so Iris selects just the useful fields and elements.
Every browser page Fetch is stored as a Snapshot, with the complete HTML and the page's assets. That is how the Playground replays the page as it appeared when you fetched it, and how your agent can go back for an image or a script-tag payload later.
The Snapshot is also what makes citation links possible. They are a sourcemap for the extracted web page. Every line of Main Markdown and every State JSON value links back to the exact spot on the original page. Your agent can put a citation link in its answer, and you can click it to see the source highlighted in the Playground. See Playground & replay.
| 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 | Markdown that is already clean | The goal is form filling |
| Product and pricing pages | A known API exposes the exact data | Extraction is secondary to interaction |
JavaScript-rendered pages, and anything with important tables, icons, layout, or hidden JSON, are where Expand helps most. The same goes for any answer you need to show the source of. When the source is a clean static article or a known API that already returns the exact data, a plain HTTP request or a simpler converter is fine.
| Layout |
| Reading order scrambles and sidebars interleave with the main content. |
| Multi-column docs pages. |
| Bot-blocked pages | A challenge page or an error, sometimes returned as if it were content. | Retail and news sites behind bot protection. |
| Dashboards and app-like pages | Showing your sources does not matter | Complex interaction determines the result |
| Marketplaces, search pages, and detail pages | The page is already structured for LLMs | The agent must operate the page, not only read it |