Existing documentation URL(s)
https://developers.cloudflare.com/speed/optimization/content/compression/#compression-between-cloudflare-and-website-visitors
What changes are you suggesting?
The list of content types Cloudflare compresses on the fly carries text/x-markdown (the pre-RFC name) and not text/markdown, the type RFC 7763 registered and the one Markdown for Agents, every .md twin and every agent-facing Markdown surface actually serves.
Two measurements disagree with each other about what the edge does today, and I cannot tell which one the list is meant to describe:
-
On 2026-07-28, on our zone with no Compression Rule, every text/markdown response shipped uncompressed (12,302 bytes that brotli takes to 5,943). That matched the list, and we added a Compression Rule to cover the type.
-
On 2026-09-18, four Cloudflare-fronted zones serving text/markdown compress it at the edge, including developers.cloudflare.com itself. Offering only zstd gets content-encoding: zstd back on three of them, which only the edge produces, so this is on-the-fly compression rather than origin gzip passing through:
I cannot rule out that each of those zones carries its own Compression Rule, which is why this is a question rather than a PR.
If text/markdown joined the default list at some point (Markdown for Agents shipping would be the obvious moment), the list needs the entry. If it did not, it would be worth a sentence saying that the registered type is NOT on the list and needs a Compression Rule, because the failure is silent: the responses that miss compression are precisely the ones built for agents, which fetch .md by preference, and nothing on the page tells you.
Additional information
The list matters one hop further than the page. miniflare copies it verbatim (packages/miniflare/src/shared/mime-types.ts, "list copied from" this URL, 47 entries, identical today) and uses it to decide which responses to re-encode in local dev, so wrangler dev treats text/markdown as incompressible whatever production does. Once the list here is settled I will open the one-line miniflare PR to match it.
Existing documentation URL(s)
https://developers.cloudflare.com/speed/optimization/content/compression/#compression-between-cloudflare-and-website-visitors
What changes are you suggesting?
The list of content types Cloudflare compresses on the fly carries
text/x-markdown(the pre-RFC name) and nottext/markdown, the type RFC 7763 registered and the one Markdown for Agents, every.mdtwin and every agent-facing Markdown surface actually serves.Two measurements disagree with each other about what the edge does today, and I cannot tell which one the list is meant to describe:
On 2026-07-28, on our zone with no Compression Rule, every
text/markdownresponse shipped uncompressed (12,302 bytes that brotli takes to 5,943). That matched the list, and we added a Compression Rule to cover the type.On 2026-09-18, four Cloudflare-fronted zones serving
text/markdowncompress it at the edge, including developers.cloudflare.com itself. Offering onlyzstdgetscontent-encoding: zstdback on three of them, which only the edge produces, so this is on-the-fly compression rather than origin gzip passing through:accept-encoding: brzstdgzipAccept: text/markdownAccept: text/markdownI cannot rule out that each of those zones carries its own Compression Rule, which is why this is a question rather than a PR.
If
text/markdownjoined the default list at some point (Markdown for Agents shipping would be the obvious moment), the list needs the entry. If it did not, it would be worth a sentence saying that the registered type is NOT on the list and needs a Compression Rule, because the failure is silent: the responses that miss compression are precisely the ones built for agents, which fetch.mdby preference, and nothing on the page tells you.Additional information
The list matters one hop further than the page.
miniflarecopies it verbatim (packages/miniflare/src/shared/mime-types.ts, "list copied from" this URL, 47 entries, identical today) and uses it to decide which responses to re-encode in local dev, sowrangler devtreatstext/markdownas incompressible whatever production does. Once the list here is settled I will open the one-line miniflare PR to match it.