Every website you visit today sends you a pile of HTML, CSS, and JavaScript — even if all you wanted was to read a blog post. Your browser downloads layout grids, tracking scripts, cookie banners, and font files before you see a single paragraph of text. For a 2000-word article, the actual content might be 12 KB. Everything around it: 2 MB.

How We Got Here

In 1989, Tim Berners-Lee wrote a proposal at CERN. The problem was simple: physicists needed to share documents across different computers. The solution was a system of linked text — hypertext — transmitted over a new protocol called HTTP. The first web page was plain text with links. No images. No layout. No scripts. Just structured words pointing to other structured words.

Early HTML reflected this. The original specification had about 20 tags — headings, paragraphs, lists, anchors. It was a markup language for documents, not a programming environment. The first browsers — WorldWideWeb, Line Mode Browser, Mosaic — were essentially document viewers. You typed a URL, you got text, you read it.

HTTP itself was designed as a content exchange protocol. The Accept header was there from the start — a client telling a server "here are the formats I understand, give me the best one you have." The early web was a conversation between a reader and a library. "I'd like this document." "Here it is."

Then the web grew. CSS arrived in 1996. JavaScript in 1995. XMLHttpRequest in 1999. Each addition solved a real problem — styling, interactivity, dynamic content. But they also shifted the web's center of gravity from documents to applications. The browser stopped being a document viewer and became a general-purpose runtime. And documents — the thing the web was built for — got dragged along for the ride.

Today, a blog post is served using the same stack as a video conferencing app. A recipe page runs more JavaScript than the Apollo Guidance Computer had memory. We've optimized relentlessly for the application web, and the document web just... got the same treatment by default.

The irony is that we already have a format perfectly suited for the document web. It's Markdown — a lightweight syntax that maps almost 1:1 to the original spirit of HTML. Headings, paragraphs, lists, links, images. The same elements Berners-Lee started with, minus three decades of accumulated complexity.

The Idea

HTTP already has a mechanism for this. It's called content negotiation. When your browser requests a page, it sends an Accept header telling the server which formats it understands. The server picks the best match and responds accordingly. We use this today for images (Accept: image/webp, image/png) and API responses (Accept: application/json).

What if browsers could send:

Accept: text/markdown, text/html;q=0.9

"Give me Markdown if you have it. Fall back to HTML if you don't."

The server checks whether a Markdown source exists for the requested URL. If it does, it responds with Content-Type: text/markdown. If not, it serves the regular HTML page. No breakage. No new protocol. Just an additional content type in a header that has existed since HTTP/1.0.

The Server Side Is Already Solved

Static site generators like Zola, Hugo, or Jekyll compile Markdown files into HTML. The Markdown source is right there — it's the input to the build pipeline. Serving it alongside the HTML output is trivial.

This blog, for example, is built with Zola. Every post starts as a .md file. A web server sitting in front of it could check the Accept header and serve the original Markdown file when text/markdown is preferred. The configuration is roughly:

# nginx pseudocode
map $http_accept $prefer_md {
    "~text/markdown" 1;
    default          0;
}

location / {
    if ($prefer_md) {
        # try serving the .md source
        try_files $uri.md $uri /index.html;
    }
    try_files $uri $uri/ =404;
}

Documentation sites built with mdBook, Docusaurus, or MkDocs already have the Markdown sources available. News sites using any CMS could expose article content as Markdown with minimal effort — most editors already store content in a Markdown-like format internally.

The pattern is: if your content pipeline starts with Markdown, you can serve it. And most text-heavy sites do start with Markdown.

The Browser Side Needs One Feature

Browsers need a "Prefer basic mode" setting. When enabled, the browser sends Accept: text/markdown with higher priority than text/html. When the server responds with Markdown, the browser renders it natively.

Rendering Markdown in a browser is not a hard problem. Every developer tool, every README preview, every note-taking app already does it. The browser would need:

  • Headings, paragraphs, lists, blockquotes — basic text structure
  • Inline images and videos — rendered as standard media elements
  • Links — clickable, obviously
  • Code blocks — with optional syntax highlighting
  • Tables — simple grid layout

That's it. No grid systems. No flexbox. No position: sticky. No JavaScript. Just a document rendered as a document.

User-Controlled Theming

Here's where it gets interesting. When the browser controls the rendering, the user controls the appearance.

GitHub already proves this model works. GitHub renders Markdown with multiple themes — light, dark, dimmed, high contrast — and users pick what they prefer. The content doesn't change. The presentation adapts to the reader.

A browser-native Markdown renderer could offer the same thing across every site you visit:

  • A default theme that looks clean and readable out of the box. Think GitHub's Markdown rendering or a good LaTeX document.
  • Built-in alternatives — dark mode, high contrast, sepia (for e-reader-like comfort), a dyslexia-friendly font option.
  • Custom user stylesheets — for those who want full control. A single CSS file that styles headings, links, code blocks, and body text. Your rules, applied to every Markdown page you visit.

The reader picks a font size, a color scheme, a line width that works for them — and every Markdown-serving site looks the way they want. No more fighting cookie banners to find a dark mode toggle. No more sites that set body text to 14px light gray on white.

Who This Is For

This isn't for every website. A shopping site with product carousels, filters, and a checkout flow needs HTML and JavaScript. A maps application needs a canvas. A spreadsheet app needs a spreadsheet engine.

But a surprising amount of the web is just text:

  • Blogs — you're reading one right now
  • Documentation — technical docs, API references, man pages
  • News articles — the article body is text, headlines, and maybe an image
  • Wikis — Wikipedia's content is structured text
  • Research papers and essays — already written in Markdown or LaTeX
  • Changelogs and release notes — almost always Markdown

For these, the full browser rendering engine is overkill. And the cost isn't just bandwidth. It's attention. Every site has its own layout quirks, its own font choices, its own idea of where to put a sidebar or how wide the content column should be. When you're reading five blog posts in a row, you're constantly context-switching between visual designs instead of focusing on words.

A basic mode collapses all of that into a consistent, reader-controlled experience.

What About AI Agents?

There's another consumer of web content that cares even less about styling: AI agents. When an LLM browses the web for information, it strips away the HTML anyway to extract text. Cloudflare recently published how switching from HTML error pages to structured Markdown reduced token usage by 98%.

If servers advertise text/markdown as an available content type, AI agents can request it directly — getting clean, structured content without scraping overhead. Content negotiation serves both human readers in basic mode and machine consumers, using the same mechanism.

The Standards Path

None of this requires inventing new technology:

  1. text/markdown is already an IANA-registered media type — RFC 7763 defined it in 2016.
  2. Content negotiation is HTTP 101 — every web server already supports it.
  3. Markdown rendering is a solved problem — CommonMark provides a spec, and every major platform already renders it.

What's missing is browser support. A browser like Firefox or Waterfox could implement this as an experimental feature:

  • Add a "Prefer basic mode" toggle in settings
  • When enabled, send Accept: text/markdown with higher priority
  • When the server responds with text/markdown, render it with a built-in Markdown renderer
  • Provide theme settings for the Markdown renderer (font, colors, width)
  • Fall back to normal HTML rendering for everything else

The fallback is key. A browser in basic mode still works on every website. It just prefers Markdown when available. Sites that don't serve Markdown are unaffected. There's no cliff — just a gradient from "every site looks like it always did" to "text-heavy sites become clean and consistent" as more sites opt in.

Full Circle

Berners-Lee's original web was a reader asking a server for a document and getting one back. Content negotiation with text/markdown is the same interaction — just with a format that's closer to how people actually write today.

The document web and the application web don't have to share a single rendering pipeline. Content negotiation lets them coexist. Sites that are documents can be served as documents. Sites that are applications stay as applications. The browser adapts based on what's available and what the user prefers.

The pieces are all there. The media type is registered since 2016. The negotiation mechanism has existed since HTTP/1.0. Markdown rendering is trivial. It just needs someone to wire them together.

Thirty-five years after a physicist at CERN wanted a better way to share text, maybe it's time we gave the document web its own lane again.