Web-to-Markdown, measured

Coverage is how much of what the visitor sees survived into the Markdown. Leak is how much of the Markdown is text the visitor never saw. The DOM walk has the lowest leak of the four by a wide margin, at comparable coverage.

Cost and time are only meaningful for the two strategies that ran as our own services. The model's 39 seconds is the benchmark's own average; the production 30-day average for that operation had been 171 seconds. The DOM walk needs only the page visit every endpoint makes, and no model.

33 pages. About half are well-known sites, each chosen because it breaks a different assumption: reference docs with definition lists, a guide with 38 code blocks, a front page built from nested layout tables, a news index rather than an article, a heavy client-rendered index, a page carrying 2 MB of inline SVG diagrams, a paywalled news homepage, docs with collapsed accordions, a product page built from sectioning <header>s. The other half are real URLs our customers asked for: e-commerce in Portuguese, an Arabic right-to-left listing, a Japanese ad-heavy homepage, a generated single-page app, a comment thread, a very long article with 98 code blocks, a single-page app that renders nothing.

Each page was loaded once in a real browser, and from that one visit we kept two things: the HTML, and document.body.innerText. innerText is the browser's own answer to "what does a visitor read", computed with the stylesheets applied, so it is the one yardstick that is not just another opinion about HTML. Every strategy was given the same HTML.

Neither number is a score on its own. Coverage below 100 is often correct: dropping a cookie banner and a footer full of navigation costs coverage and is the point. Leak is the sharper number, but it cannot tell two very different faults apart — text that was in the page but hidden by a stylesheet, which no HTML-only converter can avoid, and text that was never in the page at all, which is what a model invents. Read them together, per page, and look at the output when one moves.

Readability and the blocklist decide which part of the page to keep; their output was then written as Markdown by the same renderer the DOM walk uses. That is deliberate: a difference in Markdown style — how a table or a code fence is written — would otherwise swamp the difference that matters, which is what each strategy keeps. The model was the exception, since it did both steps itself.

Alongside the numbers, a blind judge compared the DOM walk's output with the model's for every page: it preferred the DOM walk on 24 of the 33 pages and the model on 3.

A common shortcut removes every <header> and <footer> as page chrome. In HTML5 those tags also mean "the heading block of this section", and some pages are built almost entirely from <section><header>…</header></section>. On an apple.com product page, removing every <header> took 69,306 characters of page text down to 88. The converter then turned the 88 faithfully into Markdown, and the result looked like an answer rather than a failure. The rule that works: only a page-level header or footer — one with no sectioning element above it — is chrome, and if removing chrome takes away more than four fifths of a page's text, the removal is undone.

On a long technical article with 98 code blocks, the model spent 143 seconds and returned the input HTML unchanged: no headings, no code fences, no Markdown at all. The response was well-formed and on time, so the request was recorded as a success. Checking a model's output for the shape you asked for — here, any Markdown structure — is not optional.