PDF vs Word vs HTML: which format to export Markdown to
Markdown is a great source format — fast to write, easy to version-control, readable as plain text. But it's not a delivery format. When you hand a Markdown document to someone else, you convert it to something they can open: usually PDF, Word (.docx), or HTML. Each is good at something different. Here's how to choose.
The one-line answer
- PDF — when the layout must look identical everywhere and the reader shouldn't edit it.
- Word — when the reader needs to edit, comment, or track changes.
- HTML — when it's going on the web or into an email.
PDF: fixed and final
A PDF looks the same on every device and every printer. Fonts, spacing, and page breaks are baked in, so what you send is exactly what they see — nothing reflows, nothing shifts. That makes it the right choice for anything final: a résumé, an invoice, a signed document, a report, a handout.
Strengths: pixel-identical everywhere; hard to accidentally change; prints perfectly; universally openable.
Trade-offs: not meant to be edited; the reader can't easily rework the content.
To produce one, paste your Markdown into the converter and download — or use Pandoc for scripted output. If the text comes out selectable (not an image), you've got a proper vector PDF.
Word (.docx): for collaboration
Export to Word when the document is going to be worked on — a colleague needs to add comments, a client wants to track changes, or it has to drop into an existing corporate template. Word keeps the content editable, which is exactly what PDF avoids.
Strengths: fully editable; supports comments and tracked changes; familiar to non-technical readers.
Trade-offs: the layout can shift between Word versions and machines; it's easy for someone to change your text (sometimes without meaning to).
Pandoc converts Markdown to Word directly:
pandoc notes.md -o notes.docxYou can even point it at a reference document so the output matches your organisation's styles:
pandoc notes.md -o notes.docx --reference-doc=template.docxHTML: for the web and email
If the destination is a web page, a wiki, a static-site generator, or the body of an email, HTML is the natural target — it's what browsers and mail clients read. It reflows to fit any screen size, which is the opposite of PDF's fixed layout.
Strengths: responsive; links and interactivity work; tiny file size; the native language of the web.
Trade-offs: appearance depends on the viewer's CSS and screen; not a “document” you'd formally send someone to sign.
Most Markdown tools can output HTML; Pandoc does it with pandoc notes.md -o notes.html, and many editors have a “copy as HTML” command.
Side by side
| Word | HTML | ||
|---|---|---|---|
| Looks the same everywhere | Yes | Roughly | No (reflows) |
| Editable by the reader | No | Yes | Sort of |
| Good for printing | Best | OK | Varies |
| Good for the web | No | No | Best |
| Comments / track changes | No | Yes | No |
| File you'd send to sign | Yes | Sometimes | No |
A practical rule of thumb
Ask one question: does the other person need to change it? If yes, send Word. If no — it's finished and should stay finished — send PDF. If it's going somewhere online rather than to a person, it's HTML. That single question resolves most cases.
For the “it's done, keep it that way” case — which is most documents you actually hand off — a clean PDF is what you want. Paste your Markdown into the converter and you'll have one in a few seconds.