Cloudflare Moves Markdown for Agents to Edge Streaming
The conversion path now accepts up to 6 MiB of decompressed HTML while removing token-count and content-length headers that some clients may use.
Edited by Tyronne Panaino
Cloudflare changed its Markdown for Agents conversion path on October 9, moving HTML processing into an in-process streaming engine at the edge. The official changelog entry says content is now processed as it arrives instead of being buffered and sent to a separate conversion service. The update matters to developers whose agents consume page text because it changes both the size ceiling and the response metadata their clients receive.
Cloudflare says the new path reduces conversion overhead and memory use. That is a first-party implementation claim, not a published benchmark: the entry provides no measured latency, memory consumption, throughput or conversion-quality result. The supported conclusion is therefore narrower than a general performance claim. Cloudflare has changed where and how the conversion runs, while the real-world effect still needs measurement in production workloads.
The conversion path now streams at the edge
The prior flow buffered an HTML response before sending it to a separate conversion service. The new design performs conversion in process and streams the incoming content. For a client, that changes the delivery contract as well as the internal architecture. Cloudflare no longer recalculates and returns `Content-Length` for the converted response because the Markdown body is streamed.
Applications that assumed the full response length would be known before reading the body may need to treat the result as an open stream instead. That is an implementation implication of the documented header removal, not evidence that every client will require a code change. Clients that already read until the response ends may see little difference, while integrations that allocate buffers or enforce limits from `Content-Length` should verify their behavior.
A threefold larger decompressed-HTML ceiling
The conversion limit increased from 2 MiB, or 2,097,152 bytes, to 6 MiB, or 6,291,456 bytes. Cloudflare specifies that the ceiling applies after decompression rather than to the compressed response size. Pages that previously exceeded the 2 MiB decompressed boundary but remain at or below 6 MiB can now fall inside the documented conversion limit.
That distinction is important for capacity checks. A small compressed transfer can expand into a larger HTML document, so the network payload size alone does not establish whether conversion will be accepted. The entry does not describe behavior beyond the 6 MiB limit, publish a table of supported HTML features or claim that a larger document will produce more accurate Markdown. The change expands the eligible input range; it does not prove output fidelity.
Token-count headers leave the response
Converted responses no longer generate the `x-markdown-tokens` or `x-original-tokens` headers. Cloudflare says clients that use those values must calculate token counts themselves. This moves token accounting out of the conversion response and into the consuming application when an integration still needs it.
The entry does not specify a replacement tokenizer, a canonical counting method or whether independently calculated counts should match the retired headers. Teams that use token counts for model-context budgeting should therefore test their chosen tokenizer against the models they actually call rather than assume the former metadata remains available elsewhere. That recommendation follows from the documented removal; it is not a claim that Cloudflare's prior counts were inaccurate.
Evidence quality and limits
The source is a concise first-party Cloudflare changelog. It directly establishes the October 9 release, the in-process streaming architecture, the expanded decompressed-HTML limit and the three response-header changes. It does not provide an independent test, a before-and-after latency figure, a memory benchmark, a reliability rate or evidence about Markdown accuracy on complex pages.
Internal confidence is medium. The shipped product change is confirmed by Cloudflare, while its operational gains remain vendor-stated and unquantified in the fetched evidence. Useful next checkpoints are measured conversion latency and memory use, documented failure behavior near the 6 MiB ceiling, and client guidance for token accounting after the header removal.
Status
Confirmed. Cloudflare documents the conversion and response-contract changes; performance and quality outcomes have not been independently evaluated in this run.
Sources
Update note: Last reviewed 2026-10-12. We will revise this post if Cloudflare publishes measured performance, conversion-quality evidence, limit behavior or replacement token-accounting guidance.
Sources
Drafted with AI assistance from source briefs; reviewed for citation completeness and label accuracy.