Word to PDF: lock your formatting on every device

A DOCX file names its fonts but, by default, does not contain them. When the file opens on a machine that lacks Garamond or whatever you chose, the application substitutes the nearest font it has, and the substitute almost never has identical character widths. Wider characters mean longer lines, longer lines mean extra line wraps, and extra wraps cascade into different page breaks. The one-page resume that became two pages on someone else's screen is nearly always a font substitution story.

Even with identical fonts installed, different applications lay text out differently. Word, LibreOffice, and Google Docs each implement their own line-breaking, hyphenation, and spacing logic, and historic versions of Word even adjusted layout based on the metrics of the installed printer driver. A DOCX is a description of intent, and every renderer interprets intent with its own accent. Two machines showing the same file identically is the lucky case, not the guaranteed one.

PDF removes the interpretation step. The format records each glyph's position on a fixed page, so there is nothing left for the viewing application to decide. That is why forms, contracts, and anything headed for print standardized on PDF: the layout question is settled once, by the sender, instead of separately by every recipient.

Conversion starts by running a full layout pass, the same work Word does before printing. The engine resolves styles, measures every run of text with real font metrics, breaks lines and pages, positions floating images and text boxes, and paints headers, footers, and page numbers. The output of that pass, a sequence of finished pages with absolute coordinates for every element, is what gets written into the PDF. Pagination happens exactly once, which is the entire point.

Fonts get embedded, typically as subsets. Rather than shipping the whole font file, the converter includes only the glyphs your document actually uses, which keeps the PDF small while guaranteeing the text renders identically on machines that have never heard of your font. Images pass through at their stored resolution or get resampled according to the converter's settings; text, by contrast, is written as vector glyph data, which is why PDF text stays razor sharp at any zoom while a screenshot of the same page goes blurry.

Document structure carries over as PDF features. Hyperlinks become link annotations at the same page coordinates, so URLs and cross-references stay clickable. Heading structure can map to PDF bookmarks, giving long documents a navigation pane. What does not carry over is everything live: tracked-change markup, comments, and field codes are resolved or dropped at layout time, because a PDF page has no concept of a pending edit.

Job applications lead the list. You have no control over what machine, operating system, or word processor a recruiter uses, and a resume is precisely the document where a surprise second page or a substituted font damages you. Converting to PDF means the version they open is, to the pixel, the version you approved. Unless a posting explicitly requests DOCX for its applicant tracking system, PDF is the safer default.

Anything approaching legal or official status wants the same treatment. Contracts go out as PDF so both parties sign the identical rendering and casual edits are off the table. University thesis offices, journal submission systems, and government portals commonly require PDF uploads, sometimes the archival PDF/A flavor, because they need documents that will render identically decades from now. Print shops ask for PDF because it fixes the layout and embeds the fonts, eliminating the classic reflow-at-the-print-shop disaster.

Conversion freezes whatever state the document is in, including states you forgot about. The classic failure is exporting with tracked changes visible, which has shipped internal edit histories and deleted-but-recorded sentences to counterparties more than once in every industry. Accept or reject all changes and delete comments before converting, and glance at the review pane to confirm nothing is pending.

Fields are the second trap. Tables of contents, cross-references, and date fields hold cached values that may be stale; a TOC that was not updated after a late edit will happily print wrong page numbers into your PDF forever. Update all fields, then scan the document once at page-width zoom looking for orphaned headings, stranded single lines, and images that drifted from their captions, because those flaws become permanent in the export.

Finally, verify the output like a stranger would. Open the PDF, check the page count matches expectations, click two or three hyperlinks, and confirm any unusual fonts rendered rather than substituted. Thirty seconds of inspection covers essentially every conversion failure mode that matters.

PDF is for finished documents, and forcing it earlier in the lifecycle creates friction. While a document is being co-written, reviewed, or redlined, DOCX is the right format precisely because it is editable and carries tracked changes. Sending a PDF to a collaborator who needs to revise it just obligates them to convert it back, with the reconstruction losses that entails.

A few destinations genuinely prefer Word format. Some applicant tracking systems parse DOCX more reliably than PDF, and postings that say so mean it. Translation vendors usually want DOCX because their tools segment editable text. Publishers frequently require manuscripts in Word for the copyediting workflow. The rule of thumb is simple: if the recipient will edit or machine-parse the document, send DOCX; if they should only read, sign, or print it, send PDF.

The two formats also pair well as a versioning habit. Keep the DOCX as your living master, export a PDF at each milestone that leaves your hands, and name the exports by date or version. The PDFs become an immutable record of exactly what was sent to whom, while the master stays free to evolve.