I Built Myself a Markdown Browser. Do We Really Need All That HTML?

What if the web could become a little less complicated? Dave Winer and others have been exploring the idea of a web built around Markdown instead of HTML. I liked the idea enough to build my own Markdown browser. Not one that browses the internet, at least not yet, but one that lets me explore Markdown files stored on my own computer and local network. And that small experiment got me thinking about what a Markdown-based web might look like.

I have a habit of building little software tools for myself. Usually, they start with a fairly simple question: wouldn’t it be nice if I had something that could do this particular thing? Thanks to AI-assisted coding, turning such questions into working software has become surprisingly easy. Not necessarily polished software, and certainly not always software that anyone else would want to use. But that’s not really the point. I enjoy experimenting.

My latest experiment is a Markdown Browser. At the moment, it’s a purely local application. I can use it to browse Markdown documents stored on my SSD or accessible through my local network. It doesn’t connect to websites on the public internet. So this isn’t a replacement for Firefox, and it certainly isn’t an alternative web browser in the conventional sense.

But the idea behind it is closely related to something Dave Winer, one of the pioneers of blogging, RSS and other technologies that helped shape the early web, has been discussing: why do we need all the complexity of modern HTML-based websites when so much of what we do online still consists of reading documents? Winer has been exploring the possibility of a simpler web built around Markdown. And that immediately appealed to me.

I’ve been using Markdown for quite some time, both for writing and for storing my own notes and documents. I like the fact that Markdown files are just text files. They don’t belong to a particular application or company. I can open them with almost any text editor, move them between computers, store them in Nextcloud, work with them in Obsidian, or hand them to a locally running AI model. And now I have a browser specifically for reading Markdown.

Wait, what’s wrong with HTML?

Strictly speaking, not very much. HTML is one of the great inventions of the internet. It gave us a relatively straightforward way to publish documents containing text, headings, images and hyperlinks. You could create a page using a text editor, upload it to a server and make it available to anyone with a browser. That was revolutionary. And it still works.

The problem is what happened around HTML. Over the years, websites have become increasingly complicated. A relatively simple article might now arrive accompanied by JavaScript frameworks, CSS libraries, analytics systems, advertising scripts, tracking technologies, consent-management software and numerous other components. Sometimes these additions provide useful functionality. But quite often, they have very little to do with the actual content of the page. And what exactly is the benefit of all this complexity to me, the person who simply wants to read an article on a website?

Think about it. You click a link because you want to read an article of perhaps 1,500 words. Yet your browser may need to download and process a substantial amount of additional material before you can comfortably read those words. Of course, not every website behaves this way. A carefully constructed HTML page can still be remarkably small and fast. The problem is not HTML itself, but the technological ecosystem that has grown around it. And that raises an interesting question: what if we started again, this time with the actual content as our starting point?

A web made of Markdown

Markdown was created by John Gruber, with contributions from Aaron Swartz, in 2004. The original idea was beautifully simple: make it possible to write structured documents using ordinary text, without filling them with HTML tags. The original Markdown documentation is still available at https://daringfireball.net/projects/markdown/.

A heading is simply a line beginning with a hash symbol. Two asterisks make text bold. Links and images can be included using a few characters. Even when the document isn’t rendered by special software, it remains perfectly readable. Imagine visiting a website where the article itself is simply a Markdown document. No complicated page layout. No advertising scripts. No JavaScript framework required to display a few paragraphs. Just the content, with links to other content.

A Markdown browser could retrieve that document and display it using a style chosen by the reader. One person might prefer a minimalist black-and-white layout. Another might want larger typography, a dark background or a reading experience resembling an old-fashioned book. The publisher provides the content and its structure, while the reader has much more control over its appearance. I rather like that division of responsibilities. And since Markdown already supports hyperlinks, there is no reason such a system couldn’t form a network of interconnected documents. In other words, a web.

Dave Winer and The Big Undo

Winer’s thinking goes beyond simply replacing one document format with another. His broader concern is that the web has gradually moved away from its original character as an open environment where individuals could publish, experiment and connect without asking permission from large technology companies. In his vision, Markdown could provide the foundation for something much simpler, particularly for people who primarily want to write and read.

His website, Scripting News (https://scripting.com/), remains one of the most interesting places to follow these ideas. Winer has also discussed the concept of a Markdown web browser and the possibility of creating a new environment alongside the existing web. The phrase The Big Undo is particularly appealing. It suggests that progress doesn’t always mean adding more technology. Sometimes it means reconsidering decisions made years ago and discovering that we no longer need all the complexity that followed.

This doesn’t necessarily mean abandoning everything the modern web has achieved. Interactive applications, sophisticated visualizations and countless other services genuinely benefit from technologies such as JavaScript. But perhaps we have become so accustomed to building everything as a web application that we’ve forgotten how useful a simple document can be.

And Winer isn’t the only one thinking about this

In January 2026, developer and writer Brett Terpstra published an article titled How About a Markdown Web? (https://cdn3.brettterpstra.com/2026/01/02/how-about-a-markdown-web/). His proposal is remarkably close to the kind of internet I find attractive. Terpstra imagines websites consisting primarily of Markdown documents, rendered by the browser. Readers could choose their own visual themes, while scripts, tracking technologies and externally hosted advertising would be excluded from the basic reading experience.

Interestingly, he doesn’t propose building an entirely separate internet infrastructure. Existing web servers and familiar technologies could still be used. The main difference would be what those servers deliver and what browsers do with it. He also raises the question of how publishers might earn money in such an environment, suggesting that micropayments could be one possibility. That’s an interesting complication. If we remove the advertising and tracking systems that finance much of today’s web, we also need to think about alternative ways to support the people who create its content. A simpler web doesn’t automatically solve the economics of publishing.

Another interesting response came from Manton Reece, the creator of Micro.blog (https://www.manton.org/). In October 2026, Reece discussed Winer’s ideas and suggested a somewhat less radical approach: why shouldn’t ordinary browsers simply support Markdown documents natively? His argument is reasonable. Browsers already display PDFs, images and many other document formats. Adding native Markdown rendering wouldn’t necessarily require replacing HTML or inventing an entirely new web.

Reece also pointed to a fundamental distinction between the web as a collection of documents and the web as an application platform. There is nothing wrong with either, but perhaps we should stop assuming that every document needs the machinery of an application. You can read his comments here: https://www.manton.org/2026/10/07/reading-dave-winers-notes-on.html.

I find that distinction particularly useful. Perhaps we don’t need a completely new web. Perhaps we need to rediscover the document-oriented web that has been there all along.

The advantages could be substantial

The most obvious potential advantage is speed. A Markdown document containing an article is generally much smaller than a typical modern webpage containing the same article plus navigation, scripts, stylesheets and other supporting material. A browser that only needs to retrieve and render that document has considerably less work to do. But it’s important to distinguish between Markdown and simplicity. A minimalist HTML page can be just as fast. The advantage comes from removing unnecessary complexity, not from some magical property of the Markdown format.

Security is another potential benefit. If a Markdown browser doesn’t execute arbitrary JavaScript from websites, an entire category of browser-based attacks becomes irrelevant to that environment. There are fewer opportunities for malicious scripts, invasive tracking or unexpected interactions with the user’s device. That doesn’t make Markdown inherently safe. A badly designed Markdown renderer could still contain vulnerabilities. Images and links can still introduce privacy and security risks. And Markdown implementations that allow embedded HTML need to handle that carefully. Nevertheless, a deliberately limited browser has a smaller attack surface than a fully featured browser designed to run complex applications.

Privacy could improve for similar reasons. Without third-party scripts and embedded tracking components, publishers would have fewer ways to monitor readers. Server logs, remote images and tracking parameters in links would still exist, of course. Privacy would depend on how the system was designed.

Then there is longevity. This is perhaps my favourite aspect of Markdown. A Markdown document written today should remain readable decades from now, even if the application used to create it has disappeared. You don’t need a particular vendor, subscription or proprietary file format to recover your own words. For someone who writes a lot, that’s a rather comforting thought. And there’s another advantage that has become increasingly important: Markdown works remarkably well with AI.

The unexpected AI connection

When I started using Markdown, I certainly wasn’t thinking about artificial intelligence. I simply wanted a convenient, portable way to write and organize information. But Markdown turns out to be an excellent format for working with language models. An AI system can read a Markdown document without first having to work through a complicated HTML page, identify the actual article, remove navigation elements and discard unrelated scripts or styling information. Headings, paragraphs, links and lists are already represented in a simple, structured form. This is especially useful when working with locally running AI models, where processing capacity is limited and efficiency matters.

And the idea is no longer confined to personal experiments. In February 2026, Cloudflare introduced Markdown for Agents (https://blog.cloudflare.com/markdown-for-agents/). The service allows supported websites to provide Markdown versions of their content to AI systems. An agent can request a document using the HTTP header Accept: text/markdown, and Cloudflare can convert the original HTML into Markdown before delivering it.

Cloudflare provided a striking example from its own blog. One article required approximately 16,180 tokens in HTML form, compared with 3,150 tokens after conversion to Markdown. That’s a reduction of roughly 80 percent. Those figures concern AI token consumption, not a universal reduction in network traffic or loading time. Nevertheless, they illustrate just how much material an AI system may otherwise need to process before reaching the actual content.

There is something rather ironic about this development. For years, we’ve been making websites increasingly complicated for human visitors. Now that AI agents are becoming important consumers of online information, we’re rediscovering the value of delivering content in a much simpler format. Perhaps the machines are helping us remember something we should never have forgotten.

But Markdown has limitations too

There are good reasons why HTML became the foundation of the web, and we shouldn’t ignore them. HTML provides a rich vocabulary for describing documents. It supports semantic elements, forms, accessibility features, multimedia and complex interactions that Markdown doesn’t offer by default. For a blog post, essay or technical document, Markdown may be entirely sufficient. For an online banking application, interactive map, collaborative editor or sophisticated data visualization, it probably isn’t.

Accessibility deserves particular attention. HTML has mature mechanisms for describing page structure and interactive elements to assistive technologies. A Markdown browser would need to preserve or reproduce these capabilities rather than assuming that plain text automatically makes everything accessible.

There is also the question of standards. Markdown isn’t quite as standardized as people sometimes assume. Different implementations support different extensions, including tables, footnotes, mathematical notation and embedded HTML. The CommonMark project (https://commonmark.org/) has attempted to establish a consistent specification, but not every Markdown application follows exactly the same rules. A genuine Markdown web would need agreement about which features browsers should support and how they should behave.

Then there’s design. Markdown deliberately offers less control over presentation than HTML and CSS. That’s attractive if you believe readers should determine how content looks, but it can be frustrating for publishers who want to create distinctive visual experiences. And finally, there’s the enormous amount of existing content already published in HTML. Any alternative would need to coexist with that material rather than pretend it doesn’t exist.

None of these limitations necessarily invalidates the idea. They simply suggest that a Markdown web would be particularly suitable for certain kinds of content, rather than everything.

Perhaps we should stop thinking in terms of replacement

The more I think about this, the less convinced I am that the interesting question is whether Markdown should replace HTML. Why should it? HTTP can already deliver many different kinds of documents. A server can provide HTML, Markdown, JSON, images, PDFs or whatever else a client requests. There’s no fundamental reason why a website couldn’t make the same article available in both HTML and Markdown.

A conventional browser could display the HTML version. A Markdown browser could retrieve the Markdown version. An AI agent could request whichever representation was most useful. The content could remain the same, and existing websites could participate without abandoning their current publishing systems. In fact, Cloudflare’s Markdown for Agents already demonstrates part of this principle, although its focus is machine consumption rather than creating a new reading experience for humans.

What interests me is the possibility of going one step further and making Markdown a first-class publishing format for people as well. Not just something we use to write articles before converting them into HTML, but something we can publish and read directly.

A small experiment with a bigger question

So that’s why I built my Markdown Browser. For now, it operates entirely within my own environment. It lets me explore Markdown files on my SSD and local network, rather than visiting websites on the internet. In that sense, it’s more of a personal document browser than a web browser. But using it makes me wonder what would happen if the same basic principle were extended to the public internet.

Imagine having a collection of Markdown documents on a server. Each document could contain links to other documents, perhaps on completely different servers. A Markdown browser could retrieve them, render them and allow readers to move from one to another. We already have almost all the technology needed to make that possible. The files are simple text. The hyperlinks are there. HTTP can deliver Markdown just as easily as HTML.

Of course, turning that into a genuinely useful alternative browsing environment would require additional work. There would need to be conventions for publishing, linking, rendering and perhaps discovering Markdown documents. Questions about security, accessibility and compatibility would also have to be addressed. My little browser doesn’t solve any of those problems. It wasn’t designed to. But it gives me a small glimpse of what a more document-oriented approach to browsing might feel like.

And that connects to something I’ve been exploring more broadly on Just Me: the possibility of a smaller, more personal and less commercially driven internet. An internet where independent websites matter, where hyperlinks are more important than recommendation algorithms, and where publishing doesn’t necessarily require complicated platforms or software stacks.

Markdown won’t create that world by itself. The original web already offered many of these possibilities using plain HTML. The problems we’re trying to address are partly technical, but also economic and cultural. Still, I find the idea of a Markdown web appealing precisely because it doesn’t require some extraordinary technological breakthrough. We already have the document format, the servers and the networking protocols. And we certainly have enough people who enjoy writing and reading.

Perhaps all we need is a different way of putting those pieces together. For now, my Markdown Browser doesn’t take me onto the internet. It simply lets me explore my own files. But it has certainly made me curious about what might happen if it did.