PDF, DOCX or Something Else: Choosing the Right Document Format
2026-08-04
Sending the wrong file format wastes more time than almost any other small administrative decision. The client who cannot open your file, the contract that reflows and changes its pagination, the form nobody can fill in — all avoidable by matching the format to what the recipient actually needs to do.
The question is never "which format is best". It is "what happens to this document next".
The fundamental split: fixed versus flowing
Every document format sits on one side of a line.
Fixed-layout formats (PDF, PostScript) describe where every element sits on a page of defined size. Open one on any device and it looks identical. The page breaks are the page breaks, permanently.
Flowing formats (DOCX, ODT, HTML, Markdown) describe content and structure, and let the software decide the layout. Text reflows to fit the window, the font, and the reader's settings. Page breaks are calculated, not stored, which is why the same DOCX can be 11 pages on your machine and 13 on someone else's.
Almost every format frustration traces back to using one where the other was needed.
Use it when: the document is finished, the appearance matters, and it needs to look the same everywhere. Contracts, invoices, reports, anything going to print, anything being archived.
Strengths. Universal — every device made in the last two decades can display one without special software. Layout is genuinely fixed. Fonts are embedded, so it does not depend on what the recipient has installed. It supports digital signatures, encryption and accessibility tagging.
Weaknesses. Editing is awkward by design. PDF describes the finished appearance rather than the underlying structure, which is why converting one back to an editable document is lossy and why PDF-to-Word conversion gives good results on simple documents and messy results on complex layouts.
It is also poor at reflowing for small screens. A PDF laid out for A4 read on a phone means pinching and scrolling, which is a real accessibility problem for long documents.
The common mistake: sending a PDF to someone who needs to edit it. If you want comments and changes back, send the source.
DOCX
Use it when: the recipient needs to edit, comment or continue working on the document.
Strengths. Track changes and comments are genuinely good collaboration tools. Content reflows properly. It remains the default in most professional and academic settings, so compatibility is rarely a question.
Weaknesses. Appearance is not guaranteed. Fonts you have and they do not get substituted, which changes line breaks, which changes pagination. Complex layouts, custom styles and embedded objects render inconsistently between Word, Google Docs, LibreOffice and Pages.
The common mistake: sending a DOCX as a final deliverable. The recipient sees something slightly different from what you approved, and can edit it — including after signing.
The reliable pattern is: collaborate in DOCX, deliver as PDF. Converting Word to PDF at the point of sending is a two-second step that eliminates a whole class of complaint.
ODT
The OpenDocument equivalent, native to LibreOffice and OpenOffice. It is an ISO standard and the mandated format in several public sectors.
Functionally it competes with DOCX. The practical consideration is that Microsoft Word's support, while present, is not perfect for complex documents — so sending ODT to a Word user occasionally produces formatting oddities.
Use it if your organisation or recipient standardises on it. Otherwise DOCX has broader reach.
Plain text and Markdown
Use it when: the content matters and the presentation does not, or when the document belongs in version control.
Plain text is the most durable format that exists. A .txt file written in 1985 opens perfectly today, and will in 2085. Markdown adds lightweight structure — headings, lists, links, emphasis — while staying readable as plain text.
Weaknesses. No page layout, no images embedded in the file, limited table support. Not appropriate as a client deliverable.
Its real strength is as a source format. Write in Markdown, generate PDF or HTML for delivery, and your content survives every application you will use over the next thirty years.
HTML
Use it when: the document is being read on screen at unpredictable sizes.
HTML reflows properly on any screen, which makes it the most accessible option for long-form reading. Screen readers handle well-structured HTML better than almost anything else.
Its weakness is that it is not a single file. Images and stylesheets live separately unless deliberately inlined, which makes it awkward to email as an attachment.
Images: JPEG, PNG, TIFF
Sometimes the document is a picture — a scan, a screenshot, a photograph of a whiteboard.
JPEG for photographs. Lossy, small, and blurs sharp edges — which makes it the wrong choice for text, where it produces visible artefacts around characters.
PNG for screenshots, diagrams and anything with sharp edges or text. Lossless, larger, and keeps characters crisp.
TIFF for archival scanning. Lossless, supports multiple pages, and used in professional document management. Poor browser support makes it a bad choice for sending casually.
The general rule: if a document is more than one page, it should be a PDF rather than a collection of images. Combining images into a single PDF makes them one ordered document instead of an attachment list the recipient has to open individually and guess the order of.
What about long-term archiving?
If a document needs to be readable in fifteen years, the question changes.
PDF/A is the archival subset of PDF, designed for exactly this. It forbids the features that make long-term rendering unreliable — external font references, encryption, JavaScript, embedded multimedia — and requires everything needed to display the document to be contained in the file itself.
For records with retention obligations, PDF/A is the format the standards actually name. Regular PDF is usually fine in practice, but PDF/A removes the failure modes deliberately rather than by luck.
Plain text remains the safest bet for content where formatting genuinely does not matter.
The formats to avoid for archiving are proprietary ones tied to a specific application version. The organisation that archived everything in a defunct desktop publishing format in 1998 learned this expensively.
A quick decision table
| The recipient will… | Send |
|---|---|
| Read and file it | |
| Edit and send back | DOCX (or ODT if they use LibreOffice) |
| Sign it | |
| Print it professionally | PDF, print preset, fonts embedded |
| Read it on a phone | HTML, or a PDF laid out for screen |
| Keep it for a decade | PDF/A, or plain text |
| Fill in fields | PDF form, or DOCX if the fields are complex |
The pattern that avoids most problems
Keep an editable source. Deliver a fixed-layout copy. Never treat the delivered PDF as your working file.
Nearly every awkward document situation — the contract that cannot be amended, the report whose source was lost, the form that arrives blank — comes from letting the delivery format become the only copy that exists.
Ready to try it yourself?
Open the Word to PDF tool →