Every few months, some hot take surfaces on Twitter or Hacker News: “Why you should write everything in HTML” or “Markdown is the future, HTML is dead.” And I sit there staring at my screen, genuinely wondering if the person who wrote it has actually built anything real in the last decade.
Let me be clear: this isn’t a debate. It’s a category error. Comparing Markdown and HTML is like comparing a screwdriver and a welding torch. They’re different tools for different layers of the stack, and anyone who tries to crown one as the “winner” is missing the point so badly it hurts.
I’ve been watching this play out in the AI tooling space recently. A lot of these new AI-powered writing tools are trying to force a choice on you: pick a markup format, and we’ll handle the rest. But the real problem isn’t which syntax you use. It’s that the tool’s understanding of your intent ends at the syntax boundary.
Here’s what actually matters: how the tool thinks about the content. Not whether it outputs .md or .html. If I drop a Markdown document into an AI editor, does it understand that a ## heading is a section break, or does it treat it like just another text decoration? Does it know that a bullet list under a heading is a child relationship, not just flat content?
I’ve seen tools that treat Markdown as a flat sequence of tokens, completely ignoring the structural hierarchy. And then they produce HTML that’s technically correct but semantically meaningless. Meanwhile, tools that treat HTML as a node tree can manipulate document structure like a Dreamweaver from 2025 – but they require you to write angle brackets, which looks ugly and annoys half the users.
So the question isn’t “Markdown or HTML?” The real question is: how does the tool model your content’s structure?
If the answer is “we parse Markdown into an AST and let you edit the AST visually,” then you don’t need to choose. You can have both the clean authoring experience of Markdown and the structural fidelity of HTML. That’s exactly what the good tools in the AI generation space are doing – they let you write in Markdown, but under the hood they build a rich document model that can export to HTML, PDF, or even something more exotic.
I’ve been using tools like this in my own workflows – stuff like Obsidian with plugins, or some newer AI-powered editors that treat Markdown as a surface with deep structure underneath. And I can tell you, once you experience a tool that gets this right, the “Markdown vs HTML” debate feels like arguing about whether hammers or saws are better for building a house. You need both, and a good builder knows when to use each.
But the tech community loves binary wars. It’s easier to pick a side and scream than to understand the nuance. So here’s my take: stop worrying about the syntax. Start worrying about whether your tool understands your content’s architecture. If it does, great – the output format is just a rendering detail. If it doesn’t, switching from Markdown to HTML won’t fix the underlying stupidity.
And for the love of all that is holy, don’t make your AI editor decide for you. That’s how we end up with a generation of content that’s perfectly formatted but completely soulless.