Markdown vs Rich Text Formats
Plain-text Markdown versus rich text formats like RTF, DOCX, and WYSIWYG HTML. One is a portable, version-controllable, future-proof writing standard; the other is a tangle of proprietary binary blobs and bloated markup. The pick is not close.
The short answer
Markdown over Rich Text Formats for most cases. Markdown is plain text you can read with your eyes, diff in git, grep across, and open in any editor written in the last 50 years.
- Pick Markdown if write docs, READMEs, notes, blog posts, or anything destined for git, the web, or static-site generators — and you want it readable and portable in 20 years
- Pick Rich Text Formats if producing a final-form print document with precise layout, mail merge, tracked legal redlines, or page-exact corporate templates that demand DOCX
- Also consider: Markdown for the source of truth, then export to PDF or DOCX at the very end. Author in plain text; render to rich format only when someone insists on it.
— Nice Pick, opinionated tool recommendations
Portability and longevity
Markdown is a UTF-8 text file. Open it in vim, Notepad, GitHub, an iPhone, or a terminal from 1994 — the words are right there, readable even when nothing renders it. Rich text formats are hostages. RTF is a crufty Microsoft dialect almost no one writes by hand correctly. DOCX is a ZIP of XML that bloats a one-line memo to 12KB and breaks subtly between Word versions. WYSIWYG HTML accumulates nested spans and inline styles until a paragraph is unreadable garbage. When the editor that produced a rich file dies, your formatting often dies with it; the content survives only because someone can crack the container open. Markdown has no container to crack. It degrades gracefully to exactly what you typed. For archives, documentation, and anything you expect to reread later, that is the whole ballgame, and rich text loses it.
Version control and collaboration
This is where rich text formats get humiliated. Try diffing two DOCX files in git: you get "binary files differ" and nothing else. Track changes is Word's private, lock-in answer to a problem git solved for everyone. Markdown diffs line by line — you see exactly what changed, who changed it, and you merge conflicts like code. Pull requests on prose become real. Every static-site generator, every docs platform, every wiki worth using speaks Markdown natively. Rich formats force you into a single vendor's editor and a single vendor's collaboration model, then charge you for it. If more than one person touches the document over time, plain-text Markdown under version control is not a preference, it is the only sane workflow. Rich text "collaboration" means emailing v7_FINAL_really.docx and praying.
Where rich text actually earns its keep
I do not say "it depends," but I will be fair: rich text formats are not pointless. DOCX still owns the last mile of corporate and legal life — exact page breaks, headers and footers, mail merge, signature blocks, and tracked-changes redlines that lawyers contractually demand. Print-precise layout with kerning and columns is genuinely beyond Markdown's flat model. PDF is the right final form for a contract or a brochure, and you reach it through a rich pipeline. The mistake is treating rich text as the place you author. It is a destination, not a workspace. Write in Markdown, keep that as your source of truth, and export to DOCX or PDF only at the moment someone with a letterhead requires it. Use rich formats as output, never as your living document.
Tooling, learning curve, and ecosystem
Markdown's entire syntax fits on an index card: hashes for headers, asterisks for emphasis, dashes for lists, backticks for code. You learn it in ten minutes and never open a formatting toolbar again, because your hands stay on the keyboard. Rich text editors bury you in ribbons, paste-as-plain-text rituals, and the eternal fight against autocorrect smartening your quotes into something that breaks code. The Markdown ecosystem is enormous and free: Pandoc converts it to anything, GitHub and GitLab render it, every note app from Obsidian to Bear is built on it. Rich formats fragment across incompatible editors that each interpret the spec slightly differently, so a file that looks perfect in one tool reflows into chaos in another. Markdown's constraint is its strength — fewer ways to format means fewer ways to make a mess. Simplicity that scales beats power that fragments.
Quick Comparison
| Factor | Markdown | Rich Text Formats |
|---|---|---|
| Version control / diffing | Plain text, line-by-line diffs, native git merges | Binary or XML blobs, "binary files differ", vendor track-changes |
| Portability & longevity | UTF-8 readable in any editor, future-proof | Proprietary containers that rot between software versions |
| Learning curve | Whole syntax fits on an index card | Ribbons, toolbars, paste-format fights |
| Print-precise layout | Flat model, no page breaks or kerning control | Exact pagination, headers/footers, mail merge |
| Ecosystem & conversion | Pandoc, every docs platform, every note app | Fragmented, editor-specific interpretation |
The Verdict
Use Markdown if: You write docs, READMEs, notes, blog posts, or anything destined for git, the web, or static-site generators — and you want it readable and portable in 20 years.
Use Rich Text Formats if: You are producing a final-form print document with precise layout, mail merge, tracked legal redlines, or page-exact corporate templates that demand DOCX.
Consider: Markdown for the source of truth, then export to PDF or DOCX at the very end. Author in plain text; render to rich format only when someone insists on it.
Markdown is plain text you can read with your eyes, diff in git, grep across, and open in any editor written in the last 50 years. Rich text formats lock your words inside proprietary or sprawling markup that rots the moment the rendering software changes. For anything you intend to keep, search, or collaborate on, Markdown wins decisively.
Related Comparisons
Disagree? nice@nicepick.dev