Plain Text Has Outlasted Every Format That Tried to Replace It — A 30-Year Defense of UTF-8

Every format that tried to replace plain text is either dead, dying, or quietly being converted back to plain text by someone like me at three in the morning. I’ve spent the better part of two decades writing tools that move data between formats — Word to Markdown, XML to JSON, RTF to HTML, FrameMaker to DocBook to AsciiDoc to Markdown to whatever the next thing was supposed to be. I’ve watched DocBook fade. I’ve watched XML for documents collapse under its own ceremony. I’ve watched RTF become a punchline. I’ve watched proprietary binary formats accumulate like sediment in enterprise file shares, each one a little time bomb of “we can’t open this anymore.” And through all of it, the same boring, uncool, unsexy thing kept winning: a stream of bytes encoded as UTF-8, with a few conventions layered on top.

That’s the thesis. Plain text won. UTF-8 won. Markdown won as the light-markup overlay. And the moment you stop fighting that fact and start designing systems that lean into it, your tooling gets simpler, your data gets more durable, your engineers get happier, and — this is the part that took me by surprise over the past three years — your AI integrations get dramatically better. Text is not a fallback. Text is the substrate. Everything else is a temporary lease against entropy.

I want to walk through how I came to believe this with the conviction of someone who has been burned too many times to feel polite about it. I’ll show you the specific failures I’ve watched, the migrations I’ve run, the formats I’ve buried, and the tooling decisions I’d make today if I were starting a new engineering org from scratch. And I’ll end with where I think this is going as AI chews through every document in the world and demands to be fed something it can actually read.

The Migration That Broke Me

A few years ago I inherited a content system at a mid-size SaaS company. Roughly twelve thousand Word documents — product documentation, runbooks, internal policies, training material — sitting in SharePoint. The org wanted to “modernize the docs.” That phrase always means something different to whoever says it, but in this case it meant: get this stuff out of Word, into a static site generator, with version control, search, and a workflow that didn’t involve emailing .docx files around.

I wrote the conversion pipeline. Pandoc as the workhorse, plus a layer of custom Python to fix the ten thousand small atrocities Word had committed on the original authors’ intentions. Curly quotes turned to straight quotes where they shouldn’t be. Tables nested four levels deep that no Markdown flavor could express cleanly. Images embedded as base64 in some files, as linked references in others, as OLE objects in a few horrifying cases. Track-changes residue. Comments from people who had left the company in 2014. Custom styles named “Normal_NEW_v3_FINAL” with no actual style information attached.

It took me four months. By the end I had twelve thousand Markdown files, a Hugo site, full-text search via a small client-side index, and a Git history. The total size of the Markdown corpus was about ninety megabytes. The original Word corpus was forty-one gigabytes. Forty-one gigabytes of XML wrapped in zip wrapped in proprietary metadata wrapped in versioning sediment, and the actual semantic content — the words and their structure — fit in ninety megabytes of UTF-8.

That’s a four hundred and fifty to one ratio. Not a typo. The Word format was carrying around four hundred and fifty times its actual informational weight in chrome. And every byte of that chrome was a liability: a thing that could break, a thing that locked the data to a specific application, a thing that made diffs unreadable, a thing that made search expensive, a thing that no future tool could be guaranteed to render correctly.

When I finished, the engineers who had to maintain runbooks said the same thing within a week: “I don’t want to go back.” Not because Markdown is more powerful than Word. It isn’t, in any narrow sense. But because the entire surface area of the system had collapsed to something they could understand, edit in any tool, grep through, diff in pull requests, and feed to scripts. The cognitive overhead vanished.

That migration is the moment I stopped being polite about file formats. Plain text isn’t a compromise. It’s the answer. The other formats are the compromise — compromises with vendors, with legacy tooling, with fashion, with the brief hope that “rich” formatting would justify itself. It hasn’t.

What Plain Text Actually Is

Let me be precise, because “plain text” gets used loosely. When I say plain text I mean: a sequence of Unicode codepoints, encoded as UTF-8, with no out-of-band metadata, no proprietary container, and no required rendering engine. The file’s bytes are its meaning. You can cat it. You can pipe it. You can diff it. You can compress it with the same algorithm you use for everything else and get good ratios because there’s no entropy hiding behind framing.

UTF-8 is the keystone. Before UTF-8 was universal, plain text had a real problem: which encoding? Latin-1, Shift-JIS, GB2312, Big5, KOI8-R, every Windows code page. A file claiming to be “plain text” could be unreadable on the wrong machine. UTF-8 fixed that, and the fix has been so complete that most engineers under thirty have never debugged an encoding issue that wasn’t somebody else’s mistake. The win was so total that we stopped noticing it.

Ken Thompson and Rob Pike designed UTF-8 in 1992 on a placemat at a New Jersey diner. That fact is famous and slightly mythologized but the engineering of it is genuinely beautiful. ASCII is a strict subset. The encoding is self-synchronizing — you can drop into the middle of a stream and find the next character boundary. The byte values used for multi-byte sequences don’t collide with ASCII control characters. It’s variable-length but the overhead for Latin scripts is zero. It was, and is, a near-perfect piece of design, and the world has been quietly running on it for thirty years.

On top of UTF-8 sit conventions. Line endings (LF, mostly, with a long sad story about CRLF). Indentation (spaces, mostly, with a long sad story about tabs). And then markup conventions — the structures we agree to layer on top of raw text to give it shape. JSON. YAML. TOML. XML. Markdown. CSV. The Unix mbox format. INI files. The thing they all share is that they’re text. A human can open them in vi and read them. A diff tool can show you what changed. A grep can find a string. A regular expression can extract a field. The format is legible to its tools because it’s legible to its users.

The Formats That Tried to Replace Text

I’m going to walk through the contenders, in roughly the order they tried, and explain why each one either lost or got absorbed.

RTF. Rich Text Format was Microsoft’s attempt at an interchange format for word processors. Text-based, technically. But the ceremony was extreme — every formatting decision encoded as a backslash command, every character potentially escaped, every document a wall of fonttbl and colortbl and pardplain. RTF was readable in the way that a chess game’s algebraic notation is readable: technically yes, practically no. It survived because it was the lingua franca for clipboard data on Windows. It died as an authoring format because nobody wanted to write it and the parsers were a nightmare. I converted maybe four hundred RTF files to Markdown two years ago and lost a week of my life to its quoting rules.

XML for documents. This one hurts to talk about because so many smart people invested so much in it. DocBook. DITA. TEI. The vision was beautiful: semantic markup, deeply structured, transformable to any output format via XSLT. The reality was that authoring DocBook is miserable. The tags are verbose, the rules are strict, the toolchain is heavy, and the cost of getting something wrong is high. I worked on a DocBook documentation system in 2011. The authors hated it. The build was slow. The XSLT was incomprehensible to anyone who hadn’t spent six months learning it. We migrated the whole thing to Markdown in 2017 and the team’s velocity tripled within a quarter. XML is alive in machine-to-machine contexts where it should be (SOAP is mostly dead but XMPP, SVG, and certain config domains survive), but XML for documents is a corpse. The replacement was JSON for data and Markdown for prose.

AsciiDoc. The technically superior cousin of Markdown. Better tables. Better cross-references. Better admonitions. Better everything if you measure expressiveness. And it lost. Why? Because Markdown was good enough and Markdown was already there. Network effects in markup languages are brutal. Every tool, every editor, every preview pane, every chat client, every wiki — they all support Markdown. AsciiDoc is supported by maybe a tenth of those, and the gap isn’t closing. I still recommend AsciiDoc for very specific technical documentation use cases (O’Reilly uses it, and they’re right to), but for the general case Markdown won and the fight is over.

reStructuredText. The Python ecosystem’s preferred markup. Powerful directive system, used by Sphinx, used by every major Python project’s docs. And yet — I see new Python projects defaulting to Markdown more often each year. Even within its home ecosystem, RST is losing ground. The directives are powerful but the syntax is finicky and unforgiving. Whitespace matters in ways that surprise people. The error messages are cryptic. Markdown’s looser, friendlier surface keeps winning even where RST has institutional advantages.

Notion blocks, Google Docs, Coda, every block-based editor. These are the modern challengers, and they’re interesting because they’re not really file formats — they’re database schemas wrapped in editing UIs. Your “document” in Notion isn’t a document; it’s a tree of blocks in a Postgres-shaped store, rendered through a proprietary client. You don’t own the file. You own a license to view a database row. Export to Markdown is provided as a courtesy and is always lossy. Export to HTML is closer but still bound to Notion’s idiosyncrasies. I’ve migrated three companies off Notion in the past two years and the pattern is identical: the export is incomplete, the structure is mangled, and you spend weeks reconstructing what you thought you owned. The block model is a beautiful editing experience and a terrible storage layer. The companies that build their long-term knowledge in Notion are renting, not owning.

PDF. A category of its own. PDF is not really competing with plain text for authoring — it’s an output format, a print artifact frozen for distribution. The problem is that organizations confuse PDF’s distribution role with a storage role and treat it as the canonical version of documents that ought to live in editable form. I’ve seen entire compliance regimes built on PDF as the source of truth, which means the source of truth is unsearchable, undiffable, and only barely machine-readable. PDF should be a build artifact, not a master.

Word .docx. The eight-hundred-pound gorilla. Technically OOXML, technically a zip of XML files, technically open. Practically: a sprawl of tags, namespaces, and Microsoft-specific extensions that no non-Microsoft tool implements completely. Pandoc gets close. LibreOffice gets close. They all hit edge cases that Word handles “correctly” by virtue of being the reference implementation. Every Word document is implicitly versioned against whatever version of Word you have. Open a 2003 doc in 2026 Word and the rendering will differ in small ways that nobody notices until they do. It’s the format of consensus, not the format of correctness.

Excel .xlsx. Even worse than Word for our purposes, because Excel files routinely encode logic — formulas, conditional formats, named ranges, hidden sheets. They’re programs masquerading as documents. I’ve debugged compliance bugs in Excel files where the answer depended on the order in which sheets recalculated. There’s a reason every serious data team eventually migrates from Excel to a real database with a real query language and treats the spreadsheet as a presentation layer only.

The Formats That Live Because They’re Text

Now the survivors. The formats that have either won or remain healthy decades after their introduction. Look for the pattern.

Markdown. John Gruber wrote it in 2004 as a way to write HTML without writing HTML. It was supposed to be a personal convenience. Twenty-two years later it’s the default markup for GitHub, GitLab, Stack Overflow, Discord, Slack, Reddit, Notion’s export, every AI chat interface, every static site generator, every README on every repo on the planet. The CommonMark standardization effort cleaned up the rough edges. GitHub Flavored Markdown extended it sensibly. Markdown won by being unambitious — by not trying to express more than ninety percent of authors needed, and by leaving the last ten percent to inline HTML. That restraint is its genius.

JSON. Doug Crockford didn’t invent JSON; he discovered it, in his memorable phrase. It was already there, latent in JavaScript’s object literal syntax. He wrote up the rules and the world adopted it. JSON beat XML for data interchange because it was simpler, more readable, and matched the data structures programmers already used. There’s no schema language as standard, which is a feature for the ninety percent of cases that don’t need schemas, and a problem for the ten percent that do — hence JSON Schema, hence TypeScript types, hence the cottage industry of JSON-adjacent tooling. The point is the format itself is text, the format itself is human-readable, and the entire ecosystem benefits from that.

YAML. The configuration format of the cloud era. Kubernetes, Ansible, GitHub Actions, every CI system, every Helm chart. YAML has real flaws — the Norway problem, the indentation traps, the implicit type coercion — but it’s text, it’s readable, and it’s diffable. When YAML breaks, you can see why it broke. When binary configuration breaks, you call vendor support.

TOML. Cargo’s config format, increasingly Python’s via pyproject.toml. TOML’s pitch is “YAML’s readability without YAML’s footguns.” It’s gaining ground. The fact that this competition is happening at all — at the level of which text format is best for config — is the real story. Nobody is proposing a binary alternative for general-purpose config because everyone implicitly understands that would lose.

CSV. Older than UTF-8, older than the web, older than most engineers reading this. Still going strong. Every database can export to CSV. Every spreadsheet can import it. Every data scientist deals with it daily. CSV has well-known weaknesses (escaping rules vary, no schema, no types) and yet it persists because it’s the simplest possible representation of tabular data and the cost of using it is essentially zero.

SQL. Yes, SQL is text. Schema definitions, queries, migrations — all text, all checked into version control, all diffable. The fact that SQL the query language has outlived NoSQL the movement is a parable about the durability of declarative text-based interfaces.

Source code. The biggest plain-text success story, so omnipresent we don’t think about it. Every programming language source file is plain text. Every commit, every diff, every code review. We tried binary source formats once or twice (Smalltalk images, certain visual programming environments) and the industry rejected them. The version-control story alone makes binary source untenable.

The Comparison Table

Here’s how I rank the formats I deal with most often, on the dimensions that matter for engineering durability.

The pattern is so clean it’s almost embarrassing. The top of the table is text. The bottom is binary or vendor-bound. The middle is text formats that overshot their complexity budget. There’s no successful binary document format that I’d trust to be readable in twenty years without active vendor support, and there’s no plain-text format from twenty years ago that I can’t read today.

Why Version Control Settled This

The single most underrated argument for plain text is Git. Or any version-control system, but Git in particular has eaten the engineering world and Git was designed for text. Diffs are text-shaped. Merges are text-shaped. Blame is text-shaped. The entire mental model of source control assumes line-oriented text files where you can ask “what changed in this file between these two commits” and get an answer that maps cleanly onto human reasoning.

Try to do this with a Word document. Word has track changes, and track changes is fine for one document with two collaborators. Try to do it with five hundred documents and twenty collaborators across a year, with branches and merges and reverts and cherry-picks. The model breaks. There’s no merge tool for .docx that doesn’t either fall back to Git’s binary diff (useless) or rely on vendor-specific comparison tools that don’t work in your CI pipeline. So the workflow that the rest of the engineering org takes for granted — branch, commit, PR, review, merge — is unavailable for the parts of your work that live in Word.

This is why “docs as code” is now an entire movement. The thesis is simple: if your documentation lives in the same repo as your code, in the same format conventions, going through the same review process, you get the same engineering rigor for free. The CI pipeline can lint your prose. The PR process can catch broken links. The Git history can show you who wrote what and when. The corollary is that the docs have to be in a format that Git can actually handle, which means text, which means Markdown.

I’ve watched teams adopt docs-as-code and within six months they can’t imagine going back. The mental model is suddenly continuous: code and prose are both just files in a repo. Search works the same. Editors work the same. Workflows work the same. The cognitive tax of context-switching between a code editor and a document editor disappears.

The AI Argument

Here’s where this gets interesting, and where the argument for text has gone from “strong” to “overwhelming” in the past three years. AI models — large language models specifically — are trained on text and consume text. Every input to a model is tokenized text. Every output is detokenized text. The entire interaction surface of the most important new technology in software is plain text.

What this means practically: the closer your data is to clean, structured plain text, the better AI tools work on it. I’ve built RAG systems against Markdown corpora and against Word corpora. The Markdown systems work better, full stop. The Word pipeline involves an extraction step that loses fidelity in ways that the model then has to compensate for or fail at. Tables get mangled. Lists lose their structure. Headings get demoted. The model can’t reason about a structure it can’t see.

I’ve fed entire Markdown documentation sites into Claude and GPT-class models as context and gotten useful answers. I’ve tried to do the same with Word and PDF corpora and the answers degrade noticeably even when I use the best extraction tools. The format itself is fighting the model. Every byte of binary chrome is a byte the model has to either ignore or be confused by.

This isn’t theoretical. Look at how AI tools are actually being used in engineering orgs. The codebase is searched as text. The docs are searched as text. The chat history is text. The agent’s memory is text. The agent’s tool calls are text. The agent’s output is text. AI is fundamentally a text-native technology, and we are about to see a decade of differential outcomes between organizations whose data is in text-friendly formats and organizations whose data is locked in binary containers.

I’d go further. I think the AI era is the final nail in the coffin for proprietary document formats. Companies that have spent twenty years building knowledge in Word are about to discover that their AI tools can read their git repos and their wikis and not their .docx archives. The cost of converting to text is finally smaller than the cost of not converting, because the upside has gone from “your docs are searchable” to “your docs are usable by an AI that does work for you.”

The Counter-arguments and Their Limits

I want to be fair to the formats I’m dismissing. There are real reasons text isn’t always the right answer.

Compute-bound formats. If you’re storing a billion rows of numerical data, Parquet beats CSV by an order of magnitude on every dimension that matters: size, query speed, type fidelity, schema evolution. I’m not arguing against binary formats for compute. Parquet, Arrow, ORC, protobuf, FlatBuffers — these are excellent, well-designed formats for their purposes. The argument is specifically about human-authored content and configuration. There’s a clear line between “data the computer reasons about” and “documents the humans reason about” and the right answer differs on each side.

Rich formatting. Some documents really do need precise typographic control. A book heading for a print run. A legal contract with specific signature placement. A scientific paper with equations and figures. For these, text-with-markup-plus-build-step is still the answer (LaTeX, AsciiDoctor with PDF backend, Markdown to Pandoc to anything). The source is text. The output is the binary artifact. You don’t author in the artifact; you build the artifact from the source. This is the engineering pattern of the last fifty years applied to documents, and it works.

Real-time collaboration. The strongest pro-Notion, pro-Google-Docs argument is collaborative editing. Operational transforms and CRDTs are genuinely hard, and the document UIs that ship them are genuinely good. I don’t dismiss this. But the answer is not “store in proprietary blocks forever.” The answer is “edit in collaborative UI, sync to text on disk.” Tools like Obsidian Sync, Logseq, and a growing cohort of local-first apps are showing that you can have real-time collaboration on top of plain Markdown files. The CRDT operates over text. The text is the source of truth. The collaboration is a layer.

Non-technical users. Someone will say: my marketing team won’t use Markdown. My HR department won’t use YAML. Fine. They don’t have to. But the system can convert their input to text on the way in and store it as text. The authoring interface and the storage format don’t have to be the same thing. This is the lesson that Notion got half right (good UI) and half wrong (proprietary storage). The next generation of tools — and we’re seeing it already — gives you a friendly editing surface and stores the result as Markdown in a Git repo.

What I’d Do Today

If I were starting a new engineering org from scratch, here’s the file-format constitution I’d write on day one and refer to whenever someone proposed something new.

Code, configs, docs, runbooks, policies, RFCs, ADRs, postmortems: all Markdown or other text formats, all in Git. No exceptions for “but it’s not really code.” If it’s words and structure, it’s text. If it’s structured data, it’s JSON or YAML or TOML. If it’s tabular human-edited data, it’s CSV or, if you can manage it, a small SQLite database with a text schema dump checked into the repo.

No Word, no Excel, no Google Docs, no Notion as the source of truth. These tools can exist as scratch pads or transient drafting surfaces. They cannot be where the canonical version lives. If a document graduates from draft to canonical, it gets converted to Markdown and committed. The conversion is a one-way ratchet.

PDFs and other binary outputs are build artifacts. They’re produced by a CI pipeline from text sources. Nobody edits a PDF. If the PDF needs to change, the source changes and the PDF regenerates.

Database schemas and migrations are text and live in the repo. The data itself is in the database. The shape of the data is in version control alongside the code. This is table stakes for any modern team and yet I still see orgs where the schema lives only in production.

Compute-bound formats are an explicit, justified choice. If someone wants Parquet or protobuf or whatever, they have to write up why. Not as bureaucracy — as forcing function. The default is text. The deviation needs a reason.

UTF-8, LF line endings, no BOM. Set this in .editorconfig, enforce it in CI, never think about it again. The thirty seconds of upfront discipline pay back across the lifetime of the codebase.

None of this is novel. Most good engineering orgs have been converging on these conventions for a decade. What’s new is the AI dimension making the case so much stronger that I no longer feel any need to compromise. The text-first stack is not just better-engineered. It’s also AI-ready in a way that no binary stack can be without a heroic conversion layer.

Predictions: The AI-Native Format Era

Where does this go? I have a few predictions, calibrated by twenty years of being wrong about file formats and trying to be a little less wrong each time.

Markdown becomes the default everywhere AI is involved. This is already happening. Every AI chat interface uses Markdown for rendering. Every code-assistant takes and produces Markdown. Every agent that writes a report writes it in Markdown. The format is becoming the literal interlingua of human-AI interaction. By 2030 I expect Markdown literacy to be assumed of any office worker, the way spreadsheet literacy was assumed by 2000.

Block-based editors converge on Markdown export as a hard requirement. The current generation of block editors treats Markdown export as a checkbox feature, often shoddily implemented. The next generation will treat lossless Markdown round-trip as the central design constraint. The vendors that fail this will lose to the ones that succeed, because customers are going to demand AI-readable backups of their content and “trust us, we’ll keep your blocks alive” won’t fly.

Word and Excel become extraction targets, not authoring targets, in serious orgs. They’ll persist for legacy reasons and for the long tail of users who learned them in 1998. But forward-looking teams will treat them as the input format that gets converted to text on ingestion, the way nobody serious treats faxes as a final destination for documents. The default authoring stack for the next generation of office workers is going to be Markdown-based, and I’d be surprised if Microsoft itself doesn’t ship a Markdown-first authoring product within five years.

The “AI-native” file format will not be a new format. Every few years someone proposes a new file format optimized for machine readability. Every few years it fails to displace the incumbents. The AI-native file format already exists, and it’s UTF-8 plain text with light markup. The reason is structural: AI models are trained on the text humans wrote, and humans wrote text in the formats they already use. Any “AI-optimized” format that diverges from text would be training-data-poor and would lose to the format the models actually saw billions of examples of.

Local-first and text-first converge. The local-first software movement (Ink & Switch, the CRDT crowd, the Obsidian/Logseq/Anytype ecosystem) is independently arriving at the same conclusion the docs-as-code movement arrived at: store data as text on the user’s disk, sync via standard protocols, edit through whatever UI you like. This is the right architecture. It will keep gaining ground. In ten years the idea of paying a SaaS company to host the only readable copy of your knowledge will look as quaint as paying for hosted email in 2026 looks to people who care about deliverability.

The PDF reckoning. I think we’re within five years of a real reckoning over PDF as a storage format. AI tools want to read documents. PDFs are hostile to AI. Compliance regimes built on PDF are about to face a choice: keep the PDFs and lose the AI productivity, or convert the corpus and gain the productivity. The conversion will happen. PDF will retreat to its proper role as an output format and lose its inappropriate role as a source-of-truth format.

Schema-as-code accelerates. We’re already seeing this with Pydantic, Zod, JSON Schema, OpenAPI, and the broader trend of expressing data shapes in version-controlled text alongside the code. AI tools amplify this because models are dramatically better at generating correct code when they can see the schema. Expect every serious data interface in five years to have a text-format schema definition that lives in a repo and gets reviewed like code.

The agent’s filesystem is text. When you give an AI agent a workspace, the workspace is a filesystem of text files. The agent reads them, writes them, diffs them, commits them. This is already the dominant pattern in agentic systems and it’s going to deepen. The “memory” of an AI assistant is increasingly going to be a Git repo of Markdown files, because that’s what works. Anyone building agent infrastructure on top of proprietary document formats is fighting the grain of the technology.

The Quiet Victory

What I find most striking, after all these years and all these migrations, is how undramatic the victory of plain text has been. There was no moment when everyone declared XML dead and Markdown won. There was no press release announcing that UTF-8 had displaced every other encoding. There was no funeral for DocBook. The shift happened the way most lasting technological shifts happen: through accumulated small decisions by people who just wanted things to work, who picked the option with less friction, who got tired of fighting their tools and chose the path of least resistance.

That path led to text. It’s been leading to text for thirty years. Every generation of tooling rediscovers it: the Unix folks knew it, the open-source movement knew it, the web standards crowd knew it, the DevOps tribe knew it, and now the AI engineers are learning it for themselves. The shape of the lesson is always the same: build on a substrate you can read with your eyes, change with any editor, version with any tool, transmit through any pipe, and store on any medium. Anything more elaborate than that becomes a liability the moment the elaboration’s caretakers stop showing up.

UTF-8 is going to be readable in 2076. I’m sure of this in a way I’m sure of very few things in software. Whatever Word documents I produce today have maybe a fifty-fifty shot of opening cleanly in 2046, and a much worse shot in 2076. The asymmetry is enormous. If you care about your work outliving you — your code, your docs, your runbooks, your decisions, your culture — write it in text. The format isn’t ancient because it’s primitive. It’s ancient because it works. It outlasted every replacement we tried, and it’s going to outlast the next round too.

I’ve spent a long career converting things into text. I expect to spend the rest of it converting more things into text. The job is never done because new binary formats keep appearing and existing binary formats keep accumulating. But the direction is set. The substrate is decided. Plain text won. UTF-8 won. Markdown won. The right thing to do, on any new project, is to stop relitigating those wins and start building on top of them. The leverage is enormous and the cost is nearly zero. The only thing that’s stopping most teams is habit, and habits are cheap to change once you’ve seen, even once, what working in text feels like compared to what working in binary feels like.

Three in the morning, four months of conversion work, twelve thousand documents reduced from forty-one gigabytes to ninety megabytes — that’s the experience that turned me into a believer. You don’t have to take my word for it. Pick a corner of your work that lives in a binary format. Convert it to Markdown for a week. See how it changes what you can do with it. See how it interacts with your version control, your search, your AI tools, your review process. I have never seen a team try this experiment and want to go back. Not once. The format is the substrate. Choose the durable one.