Comparisons
Plain text vs Markdown vs rich text
What each text format actually is, the jobs each one wins, and why converting between them almost always loses something on the way.
Updated 6 min read
Ask three people what a “text file” is and you can get three correct answers: raw characters, Markdown source, or a formatted document. The three are related — Markdown and rich text both grow out of plain text — but they answer different questions, and the fastest way to choose is to ask where the document is going rather than which one you like typing.
Plain text: characters, and nothing else
A plain text file is a sequence of characters with no formatting at all. Structure exists only by convention: blank lines between paragraphs, dashes for lists, capital letters for emphasis. That poverty is the feature. Every editor, operating system, and programming environment can open one, it cannot render “wrong” because there is no rendering to break, and it versions cleanly because every change is a visible change of characters. Config files, logs, and anything a machine has to read reliably stay plain text for exactly these reasons.
Markdown: plain text with a grammar
Markdown is plain text that agrees on what certain punctuation means: # starts a heading, **this** is bold, a hyphen and a space is a list item. The raw file stays an ordinary text file — readable as-is, diffable, openable anywhere — while tools that understand the grammar render it as a formatted document. Human-readable source plus reliable rendering is the combination that made Markdown the default for READMEs, documentation, and a generation of note-taking apps.
The catch is dialects. CommonMark defines the core, and platforms extend it: tables, task lists, and strikethrough are common extensions but not core, so a feature one editor supports may render as literal pipes and tildes in another. When Markdown moves between tools, the question is which dialect is on the receiving end.
Rich text: formatting as data
In a rich text document, bold is not characters around the text; it is a property stored with the text. Underneath sits HTML, RTF, or something like DOCX, and the editor shows you the result rather than the markup. That buys expressiveness the other two cannot match: fonts, colors, precise tables, images exactly where you put them, print-ready layout. It also costs transparency and portability — the file is not meant to be read raw, diffs are unreadable to people and to most version-control tools, and pasting between applications routinely reshuffles the formatting, because every editor has its own opinion about what to keep.
Where each one wins
| Plain text | Markdown | Rich text | |
|---|---|---|---|
| Opens anywhere, forever | Always | Yes — it is plain text | Needs a compatible app |
| Readable without rendering | Yes | Mostly | No |
| Structure without symbols | No | Partly | Yes |
| Clean diffs in version control | Yes | Yes | Practically no |
| Print and layout control | None | Low | Strong |
As a shorthand: if a machine is the reader, plain text. If a human is the reader and the document has to travel between tools, Markdown. If the page has to look a particular way for a particular audience, rich text.
Why every conversion loses something
Conversions are lossy in both directions, but not equally. The direction matters more than the tools doing the converting.
- Rich text → Markdown. Drops everything outside Markdown’s small grammar: fonts, colors, merged table cells, image placement, footnotes.
- Markdown → rich text. The gentlest trip. The core grammar maps cleanly onto styles, so little is lost.
- Markdown → plain text. Deletes the grammar entirely and leaves the punctuation behind as decoration.
- There and back again. Loss compounds with every hop, because each conversion re-decides what the surviving formatting meant.
Choose by destination
The formats are not rivals so much as different answers to one question: where does this document live, and who touches it next? A file that must open in ten years on unknown software wants to be plain text. One that engineers will read inside a repository wants to be Markdown. One a client will print wants to be rich text. Some editors split the difference by keeping a single underlying structure and rendering it either way — LiveNote’s notes, for instance, hold the same content in rich text or Markdown mode, because everything the editor supports can be expressed in both.
If you take one thing from this
Format is a property of the destination, not of the writer. Decide where the document will be read, and the choice between plain text, Markdown, and rich text mostly makes itself.