Markdown Is Not the Future of Writing

This post was inspired by Thariq Shihipar’s Claude/Anthropic post: Using Claude Code: The unreasonable effectiveness of HTML.

Every few years, some technically elegant shortcut escapes its original context and becomes a proposed standard for everyone else. Markdown has followed that path. It began as a lightweight way to write for the web without constantly touching HTML. For developers, documentation teams, and people living inside text editors, it solved a real problem. It made structured text portable, readable, and easy to version.

Fine. Developers should use whatever works for them.

But that does not mean writers should accept Markdown as the future of writing. From a writer’s point of view, and from the perspective of knowledge management, Markdown is too thin a container for meaning. It confuses visible formatting conventions with structure. It encourages people to think that because a document can be rendered cleanly, it has been adequately described.

It has not.

Markdown is a useful notation. It is not a rich knowledge model.
I lived through the earlier era of dot commands, reveal codes, control characters, embedded formatting instructions, and all the other visible machinery that once sat between the writer and the work. Those systems were not romantic. They were tedious. They forced writers to think like operators. They made us accommodate the limitations of machines and software.

Markdown often feels like a return to that mindset, only with better branding.
Yes, Markdown is cleaner than old formatting codes. Yes, it is easier to read than raw HTML. But the deeper issue remains: the writer is still being asked to manually carry the structural burden. Add the hash marks. Add the asterisks. Add the brackets. Add the backticks. Learn the dialect. Remember which flavor supports tables, footnotes, task lists, callouts, embeds, and metadata. Hope the next system interprets the file the same way the last system did.

That is not progress. That is a compromise being mistaken for a destination.

Writers do not just produce strings of words. Writers create arguments, examples, evidence, transitions, citations, asides, definitions, claims, counterclaims, captions, pull quotes, notes, summaries, and narrative movement. Those elements have relationships. They have purpose. They have weight. Markdown flattens too much of that work.

A Markdown heading may indicate hierarchy, emphasis, navigation, a topical shift, or simply a formatting preference. A list may represent sequence, options, priorities, evidence, instructions, requirements, or loosely related ideas. A block quote may be an actual quotation, an excerpt, a design convention, or a highlighted passage. Markdown rarely knows the difference.

That distinction is important. Knowledge management has always struggled with the gap between information storage and knowledge representation. Markdown stores content efficiently, but it does not adequately capture its context. It does not naturally capture why something matters, how it relates to other elements, what role it plays in an argument, or how it should be treated by a downstream system.

HTML, used well, gets much closer.

HTML can distinguish an article from a section, a figure from a caption, a citation from a casual link, an aside from the main body, navigation from content, and metadata from prose. It can carry identifiers, classes, attributes, accessibility cues, schema, provenance, and machine-readable relationships. HTML can render beautifully for people and remain intelligible to machines.
That does not mean writers should hand-code HTML. That would be another regression.

The real argument is that authoring tools should let writers work with meaningful structures and generate semantic HTML beneath the surface. The writer should not have to manage the machinery. The machine should. That holds true even if HTML is supplanted by an even richer, more subtle representation of knowledge (see SIDEBAR: The Formats That Were Already Trying to Solve This, for background on previous attempts).

AI’s role in the content lifecycle makes the argument against Markdown more urgent.

A document no longer simply waits to be read. AI systems summarize it, chunk it, index it, retrieve it, cite it, remix it, analyze it, convert it into training material, ingest it into knowledge bases, and drive automated workflows with it. Most modern documents become operational.

That means structure matters more, not less.

AI systems do not need more vaguely formatted text. They need better context. They need to know what is central and what is supporting. They need to know whether a passage is evidence, an example, a caveat, a quote, an instruction, a source, a claim, or metadata. They need to distinguish the body of the argument from the sidebar. They need to preserve captions, citations, dates, authorship, versioning, and relationships among ideas.

Markdown gives AI a rough outline. Semantic HTML can give AI a map.

That difference matters for writers and for organizations. AI ingestion without rich context produces brittle results. It increases the chance that systems will treat all content as equivalent, detach statements from their evidentiary base, overlook authorial intent, or misrepresent supporting material as the main argument.
For organizations trying to manage knowledge, Markdown lacks sufficient connective tissue. It makes documents portable, but portability is not the same as meaning. It creates lightweight files, but lightness is not the same as usefulness. It supports rendering, but rendering is not the same as understanding.

The argument for semantic richness is not new. The technical writing and documentation communities have been making it for decades, and they built real standards to back it up.

DITA, short for the Darwin Information Typing Architecture, emerged from IBM in the early 2000s as a way to structure content at the topic level rather than the document level. DITA forces authors to classify content as a concept, a task, or a reference before they write a word. That classification shapes everything: how content is reused, how it is assembled and how downstream systems understand what they are retrieving. DITA is not easy. It is opinionated, verbose, and built for enterprise environments with dedicated toolchains. But the underlying premise, that content type is a first-class attribute, not an afterthought, is exactly right.

DocBook took a different approach. It defined a rich XML vocabulary for technical documentation, allowing authors to tag content with enough precision that a single source could render as a printed manual, an online help system, a PDF, or a web page without losing structural integrity. DocBook’s granularity was its strength and its burden. It provided the map. It also required knowing how to read one.

Neither format caught on outside of specialized technical communities, and that failure is worth understanding. Both demanded too much of authors and too little from tools. They solved the knowledge representation problem and ignored the user experience problem. Writers did not want to manage XML tags; they wanted to write. The gap between the format and the authoring environment was never adequately closed.

That gap is where AI-native knowledge formats now have an opportunity. Projects like LlamaIndex’s document schemas, emerging structured knowledge graphs, and purpose-built retrieval-augmented generation pipelines each, in their own way, attempt to rebuild what DITA and DocBook tried to do — preserve structure, intent, and relationships — but in environments where AI can assist rather than just consume. The authoring layer is still catching up to the architecture.

The lesson from DITA and DocBook is not that structured authoring failed. It is that structure without usability is a standard without an audience. The next iteration needs to get both right.

Markdown’s advocates often celebrate plain text as durable, transparent, and future-proof. There is truth in that. Plain text has advantages. It survives platform churn. It can be searched, versioned, compared, and moved.

But writers should be wary of any argument that treats plain text as inherently superior because it is simple.

Simple for whom?
Markdown is often simple for people who already think in systems, repositories, parsers, and pipelines. It is less simple for people whose work depends on shaping meaning rather than managing syntax.

A good authoring environment should not ask writers to choose between expressive richness and technical durability. Personal computing was supposed to move us past that bargain. We have decades of experience in interface design, document modeling, structured authoring, metadata management, accessibility work, and web standards. We should not be telling writers that the best future we can offer is a text file filled with appropriated punctuation.

The future of writing should not look like a cleaned-up version of the command-line past.

The future should let writers create structured, semantically rich, machine-readable work without forcing them to see or manipulate the underlying codes. Writers should be able to identify a passage as an example, quote, warning, sidebar, citation, definition, or reusable knowledge object through the authoring interface. The system should preserve that structure in durable, open, inspectable formats.

HTML isn’t perfect, but it is closer to that future than Markdown.

None of this requires declaring Markdown useless. Markdown is excellent for notes, README files, lightweight documentation, quick drafts, developer workflows, and situations where speed matters more than semantic richness. It is a good scratchpad. It is a good interchange convenience. It is often good enough.

But “good enough” should not become the default ambition for writing, publishing, and knowledge management in the AI era.

The mistake is not using Markdown. The mistake is pretending that Markdown can carry the full burden of modern content.

Serious writing needs more than headings, bullets, links, and emphasis. Serious knowledge work needs containers that preserve relationships, context, intent, provenance, accessibility, and reuse. The closer content gets to AI ingestion and organizational memory, the less acceptable it becomes to flatten meaning into decorative shorthand.

The better standard is not “writers should write HTML.”

The better standard is this: writers should write in tools that understand knowledge structure, and those tools should produce rich semantic HTML or similarly expressive open formats underneath.

That distinction is important. Writers should not be asked to become markup clerks. They should be supported as creators of meaning. The authoring system should make structure easy to apply, inspect, preserve, and interpret by AI systems.

Markdown was a humane compromise for a less capable computing environment. It reduced friction at a time when writing for the web was harder than it needed to be, and it helped reduce the cost of token processing. But compromises have a shelf life. When a compromise starts limiting thought, context, reuse, accessibility, and machine understanding, it stops being liberating.

Markdown helped make web writing simpler, but simple isn’t the goal of communication, knowledge capture and knowledge representation. We live in a messy world, and we have spent decades devising ways to capture the underlying richness of knowledge and experience in our digital artifacts. If we want AI to understand the world, it also needs to embrace its complexities.