PDF, Word, HTML, EPUB: which format is for what

Most format arguments come down to one question: what must not change when the document travels? Every major format is an answer to that question. It fixes one thing in place (the layout, the editable structure, the reading experience, the pixels) and lets everything else move. Trouble starts when a document is stored in a format that fixes the wrong thing, and that mistake is behind most everyday document trouble.

When to use PDF

A PDF is a description of finished pages: glyphs at fixed coordinates, images in fixed boxes, on a page of an exact size. The file normally carries its own fonts, so the recipient's machine doesn't have to supply them. Use it whenever the visual form is the document: a signed contract, an invoice, a certificate, a designed report, anything that will be printed or filed. It's a poor container for content people still need to edit, and an awkward one for reading on small screens, since a fixed page can shrink but cannot reflow.

When to use Word (.docx)

A .docx file stores a document the way its author thinks about it: paragraphs, styles, headings, sections. (Under the hood it's a ZIP of XML files, which is a pleasant surprise the first time you rename one.) Layout is computed fresh every time the file opens, from the styles plus whatever fonts, printer settings and Word version the machine has. That's what makes it editable. It's also why the same file paginates differently on two computers: a substituted font runs a little wider, a different printer driver reports different margins, and by page thirty the page breaks have drifted. Word formats are for documents still being written. The standard workflow is the right one: work in Word, and export to PDF the moment the document's job changes from "being edited" to "being read". Going the other direction is a reconstruction rather than a conversion. It is possible, and that page is specific about what survives.

HTML has no fixed page

A web page commits to content and structure and leaves the presentation to the reading device. That is the reason the same page works on a phone, a laptop and a screen reader, and it makes HTML the strongest choice for anything meant to be published, searched, and read on whatever device shows up. The cost is that there is no fixed page, so "print this and it will look identical everywhere" is not a promise HTML can make. Documents that live as PDFs but deserve to be read on the web are common, and converting them mostly means recovering the structure the PDF flattened away.

EPUB and reflowable reading

An EPUB is essentially a website in a box (a ZIP of HTML chapters with a defined reading order), built so long-form text reflows to any screen and any font size. E-readers open it natively, and Amazon's Send to Kindle accepts it. It exists because novels and reports are miserable as fixed pages on a six-inch screen. The same reflow that makes it work for prose breaks anything whose meaning lives in its layout: poetry, textbooks full of figures, two-column papers. The PDF to EPUB page is specific about which documents convert well and which shouldn't be converted at all.

Plain text and Markdown

A .txt file is characters and an encoding: no fonts, images or structure, openable by almost anything and still readable in fifty years. Markdown adds just enough notation to mark headings and lists while staying readable as raw text, which has made it the native format of notes apps, wikis and developer documentation. Lately it is also the format of text fed to language models, which handle structured Markdown far better than a raw dump. When the words are what matters, extracting them from the PDF is often more useful than converting the whole document.

Page images and scanned PDFs

A PNG or JPG of a page carries only what you see. There is no selectable text or structure and nothing for a screen reader, but also nothing to go wrong, since every device on earth displays it identically. That's what keeps the workflow alive in forms that "must be a photo" and slides pasted into chat apps. A scanned PDF is the same thing in PDF packaging: photographs of paper, which cost you search, text selection and accessibility all the way downstream. Both directions are legitimate jobs, so the conversions run both ways here: pages out as images, and images bound into a PDF.

Three formats that lost: DjVu, XPS, PostScript

DjVu compressed scanned books beautifully, ahead of what PDF could do at the time, and died for want of viewers. Microsoft's XPS was a technically reasonable fixed-layout format that doubled as the Windows print pipeline's own file format, and it still lost, because almost nobody outside Windows could open one; Microsoft stopped installing the viewer by default in 2018. PostScript, PDF's own parent, was retired from the document role because a file you must execute to view is slow and a security risk, and because you can't jump to page 40 without executing the first 39. In all three cases the deciding factor was whether the person you send a file to could open the format without thinking.

Choosing in practice

• Still being written → Word or Google Docs, and keep it there until it's done.
• Finished, and the layout matters (contracts, invoices, forms, anything printed or signed) → PDF.
• Published for reading on the web → HTML, even if a PDF version exists alongside it.
• Long-form reading on devices → EPUB.
• The words alone → plain text or Markdown.
• Tabular data → CSV or a spreadsheet, never a PDF if you can help it, because a PDF table is geometry, not data.

Convert at the moment a document's job changes, and keep the original either way. Every conversion this site does runs in your browser, so trying one costs nothing.