DOCX, PDF, TXT and HTML: which document format to use

Almost every sensible choice between document formats comes down to one question: are you building something to be edited, or something to be distributed? Get that distinction right and the rest mostly follows.

DOCX: built for editing

A .docx file is Office Open XML, and despite the single-file appearance it is really a ZIP archive containing XML documents, style definitions and any embedded images. You can prove this to yourself: rename a .docx to .zip and open it, and the structure is right there. Because it is designed for editing, its layout reflows depending on the fonts, the page size and the software version on the reader's machine — which is exactly why a document can look subtly different on someone else's computer. That flexibility is a feature when the point is to keep working on the text, and a liability when you need it to look identical everywhere.

PDF: built for distribution

A PDF is a fixed page description. It stores text runs, vector drawing instructions, embedded fonts and images placed at exact coordinates, so it looks the same on every device and every printer. It bought that consistency by giving up reflow — which is also why editing a PDF is awkward and why reading one on a phone means pinching and scrolling around a page laid out for paper. Use it when the layout must be preserved: a contract to sign, an invoice, a form, anything going to print.

TXT: nothing but the words

Plain text has no formatting at all, and that is its strength. Every program on every platform can read it, it will still open in fifty years, and it is the natural format for data, notes, logs and anything a script will process. The one thing to watch is character encoding: text saved in a legacy encoding and opened as UTF-8 (or the reverse) turns non-English characters into mojibake — the garbled sequences you have seen when Korean or Japanese text goes wrong. Saving as UTF-8 avoids nearly all of it.

HTML: structured and reflowable

HTML is the only one of these that is natively a web document. It carries structure — headings, lists, tables — reflows to any screen size, and can be styled freely. If the destination is a browser, HTML is the format that belongs there rather than a PDF someone has to download and zoom around.

Which one to reach for

• A document to sign or print, that must look identical everywhere — PDF.
• A document a colleague needs to edit — DOCX.
• Notes or data you want searchable and future-proof — TXT, or Markdown if you want light formatting.
• Something to publish on the web — HTML.

What gets lost in conversion

Converting between these formats is routine, but each conversion keeps some things and drops others, and it helps to know which in advance. DOCX to TXT throws away all formatting, images and tables and keeps only the words — perfect when you want the text and nothing else. DOCX to HTML keeps far more: headings, bold and italic, lists and tables survive as real HTML tags. PDF to TXT works only when the PDF has a real text layer; a scanned PDF is just photographs of pages, so there is no text to extract and only OCR could recover it, which is a different process entirely. And Markdown to HTML turns plain notes into a styled web document. The PDF workflows guide covers the PDF side in more detail.

Thinking about the long term

If a document needs to still open decades from now, favor the formats least likely to be abandoned. Plain text is the safest bet there is, and PDF/A — a variant of PDF designed for archiving, with fonts embedded and nothing that depends on external resources — is the standard for documents that must be preserved. Proprietary editing formats change with their software; open, self-contained formats tend to outlive it.