PDF vs Word: When to Use Each Format

Use Word while a document is still being written or changed, and use PDF once it's finished and needs to look the same for everyone who opens it. That single rule settles most of these decisions. Word is a working format built for editing, so it reflows text depending on the fonts, printer drivers, and version installed on whoever's machine opens it. PDF is a delivery format built to freeze a page exactly as you laid it out. Draft in one, deliver in the other. Below is the detail: when each format genuinely wins, which is more accessible than people assume, which survives ten years in a folder, and what you actually lose converting back and forth.

What's the Actual Difference Between PDF and Word?

They solve different problems, and the naming hides that. A Word file (.docx) describes a document as content plus instructions: this paragraph is Heading 1, this text is bold, wrap it at whatever width the window is. Your computer then renders that using the fonts and settings it happens to have. A PDF describes a page as a finished picture: this character sits at these exact coordinates, in this embedded font, at this size.

That single design choice explains almost every practical difference:

Worth knowing that PDF isn't an Adobe product any more. It's an open ISO standard, ISO 32000, and the PDF Association, which serves as ISO's committee manager for the PDF standards, describes ISO 32000-2 (PDF 2.0) as the culmination of roughly nine years of work by about 30 subject-matter experts. Since 5 April 2023 the full specification has been available at no cost, where previously it was purchase-only. DOCX is standardised too, as Office Open XML, but it's far more tied to one vendor's implementation in practice.

When Should You Send a PDF?

Send a PDF whenever the document is finished and the layout matters. Specifically:

• Anything going to a client or customer. Quotes, invoices, proposals, reports. You control exactly what they see.
• Anything being signed. PDFs support digital signatures natively, and a signed PDF carries evidence of tampering if anyone alters it afterwards.
• Anything that must not be edited. Contracts, certificates, official statements, price lists.
• Anything with careful design. Brochures, menus, CVs, anything where a shifted line break ruins the page.
• Anything going to someone whose software you don't know. Every phone, tablet, and browser opens a PDF. Not everyone has Word.
• Anything you're keeping for years. More on that below.

The unglamorous reason PDF wins so often: you know what the other person will see. A Word document that looks perfect on your laptop can arrive with different fonts, a spilled table, and an extra blank page. That doesn't happen with PDF.

When Should You Send a Word File?

Word earns its place whenever the document isn't finished, or the recipient's job is to change it.

• Collaborative drafting. Tracked changes, comments, and version history are genuinely good, and PDF has no real equivalent.
• Templates other people will fill in. A Word template someone customises beats a PDF form for anything complex.
• When the recipient asks for it. Recruitment agencies often want Word CVs because they edit your contact details before forwarding. Publishers want Word manuscripts. Just send what's asked for.
• Long documents that get read on phones. Word reflows to the screen width. A PDF makes people pinch and zoom.
• Content that will be reused. If chunks of this document will end up somewhere else, keep it editable.

The mistake here is sending a Word file as the final deliverable out of habit. If nobody is going to edit it, there's no upside and several downsides.

When Is the Format Not Your Choice at All?

Everything above assumes you get to decide. Often you don't. Plenty of institutions have already picked for you, and if you're filing into one of their systems the debate is over before it starts.

The clearest example is the US federal court system. Its electronic filing platform, CM/ECF, doesn't prefer PDF or recommend PDF. The judiciary's own CM/ECF FAQ puts it flatly: CM/ECF systems are designed to accept only documents in PDF format. A .docx doesn't get rejected at the review stage. It can't be uploaded.

What's worth reading is the reasoning, because it's the same argument this whole article has been making, coming from people with no product to sell. The courts say the format was chosen because it allows a document to retain its pagination, formatting, and fonts no matter what type of computer is used to view or print the document, and they add four words that matter for anyone planning a decade ahead: it is also an open standard format.

Pagination is the quiet one there. In a legal filing, page 14 line 8 has to be page 14 line 8 on the judge's screen, on opposing counsel's screen, and in the printed record. A Word file reflows. That's not a formatting nuisance in that context, it's a broken citation.

The courts are already pushing past plain PDF

Some districts have gone further and are steering filers toward PDF/A, the archival subset covered further down this page. The Eastern District of Oklahoma's PDF/A guidance gives two reasons: to reduce security risks and to improve the ability to archive those documents. Their blunt explanation of the security half is that PDF has had many features added to it, and some of those features have created security risks.

That's a court telling you the format got too clever for its own good, which is roughly the conclusion the security section of this guide reaches by a different road.

It isn't compulsory yet. The same guidance says that although the Judiciary has not yet set a deadline for requiring all electronic files to be uploaded in a PDF/A format, all users are encouraged to begin to transition their filings to this new standard as soon as possible. Read that as a deadline that hasn't been announced rather than one that isn't coming.

Courts aren't the only place this happens. Grant portals, journal submission systems, tax authorities, procurement platforms and university thesis repositories all tend to specify a format, and a surprising number specify a version or a subset too. So before you spend any energy on which format is better, spend thirty seconds checking whether the recipient has already answered the question. If they have, their answer wins, and the only useful follow-up is whether your file actually meets the flavour they asked for.

Can the Person You Send It To Actually Open It?

This question settles more format arguments than any of the technical ones, and almost nobody asks it before hitting send. A PDF opens in every browser, on every phone, with nothing installed. A .docx assumes the person on the other end has software you can't see and can't verify.

The usual reply is that everyone has Word, or that Google Docs and LibreOffice open .docx fine. Both are half true, and the half that isn't is where documents quietly go wrong.

Start with Microsoft's own version, because it's the most generous case. Word for the web is free and opens .docx without a licence, so a lot of recipients land there. Microsoft's support documentation on using a document in the browser is refreshingly blunt about what that costs. Shapes, charts, SmartArt, WordArt and equations are preserved in the document, but in Word for the web, as Microsoft puts it, they may appear as placeholders and cannot be edited, moved, or resized. Page layout is preserved but can't be edited. More sophisticated table features such as table styles, cell size, text direction and sort order survive inside the file but can't be configured in the browser.

And some files don't open at all. Microsoft states plainly that Word for the web can't open documents that are encrypted with a password or protected with Information Rights Management. So the password you added to keep the file safe is the reason your recipient is looking at an error message instead of your report.

The gap runs deeper than display. Microsoft's web versus desktop feature comparison lists macros, mail merge, compare and merge revisions, section breaks, columns, watermarks, cover pages, embedded objects, signature lines, and bibliography, captions and citations as desktop only. If your document leans on any of those, a browser recipient isn't seeing what you built.

Third-party apps are a different flavour of the same problem. Google Docs and LibreOffice both read .docx, and both re-render it through their own layout engines rather than Word's. Fonts you have and they don't get substituted. Spacing shifts. A table that fitted on one page grows onto two. Nothing is corrupted, which is exactly what makes it easy to miss. The document just isn't quite the one you wrote.

None of this touches a PDF, because a PDF isn't asking the reader's software to lay anything out. The page is already laid out. That's the whole point of the format, and it's why the "will it look right" question stops existing the moment you export.

So the rule that falls out of it:

• If you don't know what software they have, send PDF. That covers clients, job applications, anything going to a stranger, and anything likely to be opened on a phone.
• Send .docx only when you know they'll edit it, and ideally when you know what they'll edit it in. "Here's the template, change the highlighted bits" is a fair reason. "Here's the final report" isn't.
• If it needs a password, it has to be PDF. A protected .docx locks out every browser recipient. Our guide on how to password protect a PDF free covers the version that works everywhere.
• Send both when the stakes are high. PDF so they can read it, .docx so they can work with it. One extra attachment removes all the guesswork.

Which Format Is More Accessible?

This is the part most PDF vs Word comparisons skip, and the honest answer probably isn't what you'd guess. A properly structured Word document is usually more accessible than an average PDF, and HTML beats both.

The UK's Government Digital Service made the case bluntly: information published in a PDF is harder to find, use and maintain than the same information in HTML. At the time of writing they were hosting around 200,000 PDFs and publishing tens of thousands of new ones every month, which is why the problem mattered enough to write about. Their specific complaints are worth knowing because they apply to your documents too. PDFs open in a new window or app and break the user's context. They don't reflow, so magnifying the text means scrolling sideways. They're rarely updated once published, so they go stale and accumulate broken links.

The accessibility point is sharper still. GDS cited a 2016 assistive technology survey finding that screen magnifiers and screen readers are the most commonly used assistive technologies, and those are precisely the tools PDFs cause the most trouble for.

The US federal position has landed in the same place. Section508.gov states plainly that PDFs are often not the most accessible or mobile-friendly option and that federal policy now requires agencies to prioritise HTML formats, using PDFs only when necessary. The UK's guidance on publishing accessible documents says HTML should be your first choice whenever possible.

None of that makes PDF unusable. It means a PDF is only accessible if someone made it accessible: proper tags, a reading order, alt text on images, real text rather than a scan. Our PDF accessibility guide walks through what that involves, and the W3C's PDF techniques for WCAG is the reference implementers use.

If you want a standard to hold a tagged PDF to, there are now two editions, and it helps to know which one you're looking at. PDF/UA-1 covers files written as PDF 1.7. In March 2024 ISO published ISO 14289-2, PDF/UA-2, a 42-page standard written specifically for PDF 2.0 files. You don't need to read either one. But check what your export tool actually claims. "Tagged" on its own promises very little, while a file that claims PDF/UA conformance has signed up to a checklist someone can test it against.

Which Format Should You Use for Maths and Equations?

Word, and this is the one place where the whole shape of this guide flips. Everywhere else the advice runs towards PDF once a document is finished. Put equations in it and the ordering reverses.

The reason follows directly from what PDF is for. A PDF fixes appearance and treats structure as secondary, which is the argument in its favour almost everywhere on this page. An equation is the worst possible case for that trade. Exported to PDF, a fraction becomes a set of glyphs positioned near a horizontal line. It looks right. There is nothing left saying it is a fraction.

What keeps the meaning is MathML, a markup language for representing mathematical notation so that software can work with the structure rather than the picture. The W3C specification is the standard behind it.

The University of Washington's accessible technology team, whose tagged PDF guidance this article draws on elsewhere, sets out where that leaves the two formats. Their guidance on accessible maths makes three points worth carrying away.

• Word equations already carry MathML. Native Office Math equations contain MathML underneath, and Word adds keyboard access and audio cues on top. The structure you need is there if you use the equation editor rather than pasting a picture.
• PDF support exists but is patchy. Accessible maths in PDF improved during 2026, and it's still limited by what readers and assistive technology actually implement. Their assessment is that NVDA and JAWS support it only in Firefox, and that there's no known support on macOS.
• The recommended order isn't the one this guide usually gives. They rank an HTML page first, native Word or PowerPoint second, and PDF last. Exporting to PDF is specifically flagged as something that can lose accessibility features you already had.

That HTML-first ranking should look familiar. It's the same conclusion the UK Government Digital Service reached about publishing generally, cited earlier in this guide, arrived at from a completely different direction.

So the practical rule. If your document contains real mathematics and anyone might need a screen reader, send the Word file, or better, publish it as a web page. If a PDF is genuinely required, build the equations with the equation editor rather than as images, tag the document properly, and send the editable original alongside it rather than instead of it.

And the thing not to do, regardless of format: screenshot the equation. An image of maths carries no structure at all, fails at any zoom level, and cannot be fixed later without retyping it.

Do Accessibility Rules Actually Apply to Your Documents?

For a lot of people, yes, and the rules name PDF and Word specifically rather than talking vaguely about websites. If you work for or with a US state or local government, this is now a legal obligation with a date on it.

The Department of Justice published a final rule under Title II of the Americans with Disabilities Act on 24 April 2024, setting WCAG 2.1 Level AA as the technical standard for web content and mobile apps provided by state and local government entities. The part that matters here is scope. The rule covers what it calls conventional electronic documents, and it lists them: PDFs, word processor file formats, presentation file formats, and spreadsheet file formats. Posting a PDF instead of a web page doesn't put you outside the rule.

The deadlines moved recently, so check the current ones rather than a guide written in 2024. In April 2026 the Department published an interim final rule extending compliance by a year. Per ADA.gov's first-steps guidance, entities with a population of 50,000 or more now have until 26 April 2027, and entities under 50,000 or any special district government have until 26 April 2028.

Two exceptions are worth knowing because they narrow the job considerably. Preexisting conventional electronic documents get an exception if they were posted before the compliance date and aren't currently used to access services, programs, or activities. And individualized, password-protected documents about a specific person, property, or account, think a tax bill or a utility statement, don't have to meet WCAG 2.1 either.

There's a second US rule that catches a lot of people who read the above and concluded none of it applies to them. In May 2024 the Department of Health and Human Services adopted web and app accessibility requirements under Section 504 of the Rehabilitation Act, again on WCAG 2.1 Level AA. The reach is the interesting part. It binds recipients of HHS financial assistance, which pulls in private hospitals, clinics, health plans and plenty of smaller providers, not just government bodies.

Those dates moved too, and in the same direction. An interim final rule effective 7 May 2026 pushed the deadline for recipients with 15 or more employees from 11 May 2026 out to 11 May 2027, and for those with fewer than 15 employees from 10 May 2027 to 10 May 2028. So if you produce patient letters, consent forms or benefit statements as PDFs and you take HHS money, the tagging question is a compliance question for you, on a clock.

If you're outside US government work and outside healthcare, neither of these binds you. But don't stop reading there, because a different set of rules reaches further still into the private sector, and that's the next section. Either way the practical advice doesn't change: publish reference content as HTML, and if you do ship a PDF, tag it properly.

Do European Rules Reach Your Documents Too?

Quite possibly, and this is the bit that catches businesses out. The American rule above applies to state and local government. The European one applies to companies selling things.

The European Accessibility Act, formally Directive 2019/882, obliged Member States to write it into national law by June 2022, and its requirements became applicable on 28 June 2025. The European Commission's own list of what it covers is heavily commercial: computers and operating systems, smartphones, ATMs and ticketing machines, TV equipment, telephony services, audio-visual media access, passenger transport by air, bus, rail and water, banking services, e-books, and e-commerce.

Read that list again with document formats in mind. E-commerce, banking and e-books are not government functions. If you sell online to consumers in the EU, run a bank, or publish e-books, you're in scope in a way you never were under the ADA rule, and the terms and conditions, statements, invoices and product documents you attach are part of the service you're providing.

Two things make this bigger than it first looks:

• It follows the customer, not your address. The obligation attaches to offering the service to consumers in the EU. Being headquartered in Singapore, London or Texas doesn't put you outside it if that's who you're selling to.
• It's a directive, not a regulation. That means each Member State passed its own implementing law, so the enforcement bodies, the penalties and some of the fine print differ by country. There is no single EU text you can read and be finished.

Being straight about the limits of this section. There are carve-outs, including relief for the very smallest businesses and a disproportionate burden argument, and there's a long transition for services already running before the date. I'm not going to put numbers on those here, because the version that binds you is your Member State's implementing law rather than the directive itself. If you think you're in scope, that's a question for a lawyer in the relevant country, not for a PDF guide.

What it changes about your format choice is simple enough though. A PDF attached to a purchase, a statement or an e-book is part of the service, so the answer stops being "export to PDF and move on." Either publish the content as HTML, which is the easier path to accessible, or export a properly tagged PDF with real headings, alt text and a reading order. Untagged PDF was already a poor choice. In these sectors it's now a compliance question.

What If Your Document Started in Google Docs?

Then the choice isn't really PDF versus Word. It's which export button you press, and one of them quietly costs you a lot more than the other.

This guide has treated the decision as a straight two-way comparison, which is how most people frame it. But a large share of documents in 2026 never start life as either format. They start in a browser, in Google Docs or something like it, and only become a .pdf or a .docx at the moment somebody needs to send them somewhere.

That origin matters more than you'd expect, and the reason is tagging.

The tagging problem nobody mentions

Everything the accessibility sections above describe depends on a PDF being tagged. A tagged PDF carries a structure tree, similar in spirit to HTML, marking which text is a heading, which block is a list, which cells belong to a table, and what the alternative text for an image is. Strip that away and you have pixels arranged on a page. A screen reader gets a wall of undifferentiated text, if it gets anything useful at all.

Here's the part that catches people out. Not every application produces tagged output.

The University of Washington's accessible technology guidance on tagged PDF is direct about which tools do and don't. Microsoft Word, PowerPoint and Adobe InDesign export tagged PDFs. Google Docs and Google Slides do not, and neither do most other authoring tools.

Read that again if you write in Google Docs, because the implication is uncomfortable. You can structure your document perfectly, using real heading styles rather than bold text, doing everything the accessibility guidance asks. Export it to PDF and that structure does not travel. The visual hierarchy survives. The machine-readable one doesn't.

Which means a Google Doc exported straight to PDF can fail the accessibility standards discussed earlier in this guide while looking, to you, completely fine.

What to do instead

Three options, roughly in order of how much work they are.

Route through Word. Download the Google Doc as .docx, open it in Word, and export the PDF from there. Tedious, and it's the fix most people can actually action today. Your headings need to be real heading styles in the original for this to help, so the structure survives the handoff.

Send the .docx instead. If the recipient doesn't need a fixed layout, the Word file keeps its structure and stays editable. The earlier section on when to send a Word file applies unchanged.

Or don't make a document at all. This is the option the guidance keeps pointing at. Section508.gov notes that federal guidance directs agencies to prioritise HTML and use PDFs only when necessary, and the UK's Government Digital Service reached the same conclusion years earlier. If the thing you're producing is information for people to read rather than a form or a record, a web page beats both formats on accessibility, on mobile, and on being findable.

Untagged PDFs can be fixed after the fact. Acrobat Pro can auto-tag a document or let you build the reading order by hand. But that's remediation, it takes real time, and it has to be redone every time the document changes. Getting the export right is cheaper than fixing the output forever.

Which One Survives Long-Term Storage?

PDF, and it's not close. There's a whole ISO standard for exactly this: PDF/A, defined in ISO 19005, whose stated purpose is to preserve a document's static visual appearance over time, independent of the tools and systems used to create, store, or render it.

PDF/A does that by refusing the things that rot. Fonts must be embedded rather than referenced, so the document can't change when a font disappears. External dependencies, JavaScript, and encryption are excluded. The file has to carry enough metadata to describe itself. The family has grown alongside the core standard: PDF/A-1 was built on PDF 1.4, PDF/A-2 on PDF 1.7 as formalised in ISO 32000-1, and PDF/A-4 on ISO 32000-2:2020, which is PDF 2.0.

A .docx has no equivalent. It's tied to a specific application's rendering behaviour, and open it in fifteen years on whatever Word has become and the layout may well have drifted. That's why archives and records offices standardise on PDF/A. The UK's National Archives publishes format guidance for official publications on exactly these grounds.

So for anything you need to still be readable and unchanged years from now, export PDF and keep the Word original alongside it if you might need to edit again.

Which Format Do You Send to a Commercial Printer?

A PDF, but a particular kind of PDF, and the one Word exports by default usually isn't it. Never send the Word file. This is the job where "it looked fine on my screen" costs you a print run.

Same logic as the archiving section above, aimed at a different problem. PDF/A is a constrained subset that removes anything which might render differently in twenty years. There's a parallel family built to remove anything that might render differently on somebody else's press, and it's called PDF/X, defined across the ISO 15930 series under the title Graphic technology, prepress digital data exchange using PDF.

The constraints tell you what actually goes wrong in printing. Under PDF/X-4, which is ISO 15930-7, every font must be embedded, an output intent ICC colour profile has to be embedded so the press knows what colour space you meant, and the file may not rely on external data, password protection, visible annotations or JavaScript. It does allow colour-managed CMYK, grey, RGB and spot colour, along with transparency and layers.

The older PDF/X-1a, ISO 15930-4, is stricter: CMYK and spot colour only, no transparency and no layers. Plenty of print shops still ask for it, which is why the first thing to do is ask which flavour they want rather than guessing. A printer who specifies PDF/X-1a and receives a transparency-heavy PDF/X-4 file is going to send it back.

Now the part that catches people out. A plain PDF exported from Word will often be rejected or come back wrong, and the reasons are structural rather than fixable with a better export setting:

• Colour. Word works in RGB, presses work in CMYK. The conversion happens somewhere regardless, and if you don't control it, the printer's software guesses. That's how a brand blue arrives looking purple.
• Bleed. Anything printing to the edge of the paper needs artwork extending past the trim line, typically 3mm. Word has no concept of bleed, so a full-bleed background in a Word document will trim to a thin white line down one side.
• Fonts. PDF/X requires embedding. A normal export usually embeds too, but "usually" is doing a lot of work in a file you can't check after you've sent it.
• Resolution. Images pasted into Word at screen resolution stay at screen resolution. They look fine on a monitor and print soft, and no export setting adds detail that was never there.

Which points at the real answer for anything going to a commercial press: don't start in a word processor. Word is a fine tool for documents that will be read on screens or run off an office printer, and it was never built for prepress. A flyer, a business card or anything with artwork bleeding off the edge belongs in layout software from the start, exported to whichever PDF/X flavour the printer named.

And keep this in proportion. If you're printing to the machine down the hall, or sending a document someone will run off at home, none of it applies. A normal PDF prints exactly as you'd expect, and the whole PDF/X apparatus exists for commercial print runs where a mistake means reprinting a thousand copies rather than pressing Ctrl+P again.

Are Both Formats Actually Open Standards?

Yes, and this surprises people. The usual framing is that PDF is the open one and .docx is Microsoft's proprietary lock-in. That stopped being true nearly two decades ago, and knowing it changes how you should think about the longevity argument.

PDF became an ISO standard as ISO 32000, which the article has already leaned on. But .docx has one too. ISO/IEC 29500, published as Office Open XML File Formats, defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The standard's own stated goal is telling: to be capable of faithfully representing the pre-existing corpus of documents produced by Microsoft Office applications up to the point the standard was created.

There's a third one worth knowing about. ISO/IEC 26300 is the OpenDocument Format, submitted by OASIS and approved by ISO and IEC in 2006. It's the .odt you get from LibreOffice, and it's the format several governments standardised on precisely to avoid depending on one vendor.

So what does that mean for you? Mostly that "open standard" is a weaker guarantee than it sounds. All three formats are documented and published. What actually differs is how much of the real behaviour lives in the spec versus in one application's implementation. A .docx documents its markup thoroughly, but the way a specific version of Word lays out that markup on a page is not something the standard pins down. PDF's whole design goal is the opposite: fix the appearance, and let the structure be secondary.

Which leaves the practical advice where the archiving section already put it, but for a better-stated reason. Use PDF, ideally PDF/A, when you need what the reader sees to be what you sent. Keep the editable original in .docx or .odt when you need to change it later. Being an ISO standard doesn't make a Word file render identically in fifteen years. It just means somebody could write software to read it.

Does Converting Between Them Lose Anything?

The two directions are not remotely equal, and this trips people up constantly.

Word to PDF is clean. You're taking a document with structure and rendering it to a fixed page. Everything you had is preserved or improved: fonts embed, layout locks, headings can carry through as bookmarks and tags. Use the built-in Export or Save As PDF rather than printing to PDF, because printing usually discards the structure that makes the file accessible.

PDF to Word is reconstruction. You're asking software to look at fixed characters on a page and guess what the paragraphs, tables, and styles were. It's genuinely hard, and results vary with the document. Simple text converts well. Multi-column layouts, complex tables, and heavy design usually need cleanup afterwards. And if the PDF is a scan, there's no text at all until OCR runs, and OCR makes mistakes.

The practical takeaway: keep your editable original. Converting a PDF back to Word is a recovery operation, not a workflow. Our PDF to Word guide covers how to get the best result when you have no choice, and the PDF to text guide is often the better route if you only need the words.

Which Format Works Better When Software Has to Read It?

Word, and by a wide margin. This barely mattered a few years ago and matters a lot now, because documents increasingly get read by machines before a person ever opens them: applicant tracking systems, contract review tools, search indexes, and whatever AI assistant someone drops your file into.

The reason is baked into what each format is for. A .docx is structured markup. As ISO/IEC 29500 puts it, the format defines XML vocabularies for representing word-processing documents, so a heading is tagged as a heading and a table is tagged as a table. Software doesn't have to guess.

A PDF doesn't work that way by default. It records where marks go on a page. It does not inherently record that this block is a heading, that these two columns should be read left then right, or that these cells belong to one table row. That information exists in a PDF only if the file was tagged, which is what ISO 14289, the PDF/UA standard, exists to specify. Its requirement is explicit: content shall be marked in the structure tree with semantically appropriate tags in a logical reading order. Plenty of PDFs in the wild have no tags at all.

Notice that this is the same root cause as the accessibility problem discussed earlier. A screen reader and a data extraction tool want the identical thing, which is a logical reading order. An untagged PDF denies it to both. Fixing tagging for accessibility fixes machine readability at the same time, which makes it a rare case of doing the right thing paying twice.

Where this bites in practice:

• Multi-column layouts. Extraction can interleave the columns, so your two neat columns come out as alternating half-sentences.
• Tables. The text usually survives. The relationship between rows and columns often doesn't, which turns a rate card into a list of loose numbers.
• Scanned pages. A PDF of a photographed document contains no text at all until OCR is run over it, and OCR on a skewed or low-contrast scan introduces its own errors.
• Headers, footers and page furniture. These get pulled into the body text, so a fifty page report arrives with a company name wedged into every third paragraph.

So the rule of thumb splits by audience. If a human is the reader and the presentation matters, send PDF. If software is doing the reading first, whether that's a recruiter's system, a compliance tool or an AI summariser, the Word file will produce noticeably cleaner results. And if you must send a PDF into a machine pipeline, export it from a properly styled source document with real headings rather than manually formatted text, because that's what generates the tags.

Which Format Do You Hand a Translator?

The Word file, and it isn't close. This is one of the few decisions in this guide where the usual "PDF for final, Word for working" rule stops being a preference and becomes the difference between a routine job and an expensive rebuild.

Two separate things go wrong when you send a PDF, and most people only anticipate the first.

The first is getting the words out. As the section on software reading your document covers, a PDF records where each character sits on a page rather than a flowing stream of text. Pull that into a translation tool and you get sentences broken at every line ending, tables that arrive as loose text, and reading order that follows the page layout rather than the sentence. Someone has to repair all of it before a single word is translated.

The second is worse, and it's arithmetic. Translated text is a different length from the original, and a PDF's layout cannot move.

The W3C's article on text size in translation reproduces IBM's long-standing guidance on how much English grows when translated into other European languages, and the figures are larger than most people expect. A source string of up to 10 characters averages 200 to 300 percent of its original length. Eleven to 20 characters lands at 180 to 200 percent. Even past 70 characters, where expansion is mildest, the average is still around 130 percent.

The article's worked example is a single word. Flickr's "views" came out 3.0 times longer in Italian, 2.8 in German, and 2.6 in both French and Portuguese. Chinese ran to 1.2. Korean actually came in shorter, at 0.8.

Sit with what that means for a fixed page. A table header, caption or button label that fits neatly in English needs roughly three times the room in Italian. In a Word file the paragraph simply reflows and the page repaginates. In a PDF nothing moves, so the text either overflows its box or has to be shrunk, and someone is now rebuilding your layout by hand in every language you ship.

What the industry actually runs on

Professional translation doesn't happen in the document you sent. Text gets extracted into an interchange format, translated with memory and glossary tools, then merged back.

The standard for that is XLIFF, the XML Localisation Interchange File Format, maintained by OASIS and now at version 2.2. It exists so that any content owner can hand a job to any provider using any conformant tool, without the file format being the problem.

A DOCX drops into that pipeline cleanly, because the structure is already there to extract. A PDF doesn't. That's why agencies frequently quote extra for PDF-only source material, or quietly rebuild the document in a word processor before they start and pass the cost on either way.

The font trap

Here's one that surprises people who assume a PDF is self-contained.

A PDF embeds the fonts it uses, which is exactly why it looks identical everywhere. But it embeds the glyphs for the language it was written in. Translate into Greek, Russian, Arabic, Japanese or Chinese and the embedded font almost certainly has no glyphs for those scripts at all. So even a perfectly executed edit is silently changing your typeface, and the visual consistency that made you choose PDF in the first place is gone.

A workflow that avoids all of it

• Keep the editable source. This is the entire lesson. Archive the Word file alongside the PDF you issued, because the day someone asks for a second language is the day you find out whether you still have it.
• Send both files. The Word file to translate from, and the PDF marked clearly as reference only so the translator can see the intended layout and where things sit.
• Budget layout time per language, not once. You'll re-export a PDF for each one, and German and Italian will need more page than English did.
• Leave room when you design. Text set tight against a box or a column edge is text that breaks in translation. Give it slack you don't currently need.
• Treat right-to-left as a rebuild. Arabic and Hebrew mirror the whole layout, not just the words. That's a redesign, not a reflow, and no format saves you from it.

And if the PDF genuinely is all you have, convert it to Word first, fix the structure by hand, and translate from the repaired file. Our guide to converting PDF to Word covers what that conversion does and doesn't preserve. Just don't expect the output to be clean enough to translate from without someone reading it through.

The short version: PDF is the output of a translation job, never the input.

Which Format Is Safer to Open?

Here's an angle most format comparisons skip entirely, and it's the one that made Microsoft change how Word behaves by default. A .docx can carry executable code. That's not a bug, it's what macros are for, and attackers have spent years abusing it.

The UK's National Cyber Security Centre doesn't hedge about what's at stake. Its guidance says malicious macros can do almost anything that other malware can do to your system, including emulating ransomware, stealing data, and emailing itself out to your contacts. Its recommendation is equally blunt: the only effective way to protect your systems against malicious macros is to disable macros in all Office apps and ensure that users cannot re-enable them.

Microsoft agrees, and acted on it. Its documentation on blocking internet macros opens by stating that VBA macros are a common way for malicious actors to gain access to deploy malware and ransomware. So Office now blocks macros in files that came from the internet, and the rollout has specific dates worth knowing. Current Channel got the change in Version 2206 on 27 July 2022, after a preview in Version 2203 from 12 April 2022, and the Semi-Annual Enterprise Channel followed with Version 2208 on 10 January 2023. Seven apps are covered: Access, Excel, PowerPoint, Project, Publisher, Visio and Word.

Two limits on that protection matter to you. It only applies on Windows, so Office on a Mac, on Android or iOS, or Office on the web isn't covered by the change. And it works off Mark of the Web, the tag Windows adds to files from the Internet or Restricted Sites zones. Files carrying ZoneId 3 get blocked. Files from a trusted site, ZoneId 2, don't. Which means a macro file that reaches you through a route that never sets that tag doesn't trigger the block at all.

None of this makes PDF harmless. PDFs can contain JavaScript and embedded files, and malicious PDFs are a real category. But the asymmetry is genuine: nobody sends a PDF expecting the recipient to enable scripting, whereas "enable content to view this document" is a phrase that has separated a lot of people from their data. It's also why PDF/A excludes JavaScript and encryption outright, as covered in the archiving section above.

The practical rules that follow are short. Send a PDF when the recipient has no reason to run anything. If you receive a .docx or .xlsm you weren't expecting and it asks you to enable content, don't, and check with the sender through a channel you already trust. And if you're sending externally and there's no editing to be done, converting to PDF removes a whole class of question from the recipient's mind. Our PDF security guide covers the risks that do apply on the PDF side.

Which Format Should You Redact In?

Word. Which sounds backwards, since PDF is the format you send. But this is the one job where doing it in the delivery format is how people get burned, and the failures are spectacular enough that courts have written guidance about them.

The problem is simple to state. Drawing a black box over text in a PDF, or running the highlighter tool across it, doesn't delete the text. It draws a shape on top of it. The characters are still sitting in the file, and anyone can select them, copy them, and paste them somewhere else.

The US District Court for the Eastern District of Tennessee published guidance on this after enough people got caught. Its opening line notes that prosecutors, the Justice Department, lawyers for a large corporation and even a federal district judge have all learned this painfully. The example it walks through is a November 2010 opinion where black bars appeared over grand jury testimony, and as the court's own guidance puts it, the bars only obscure the text beneath them, they do not erase it. A simple cut-and-paste renders the blacked-out text readable. The same guidance points at earlier instances in 2006 and before, so this isn't a one-off.

Their conclusion is the part worth memorising, and it's a direct instruction about which format to work in:

• Documents are extremely difficult to redact properly when working directly on the PDF itself. PDF was never designed to be edited in place, and the annotation and commenting tools people reach for are the ones that cover text rather than remove it.
• The best and safest way is to edit the original word processing document to remove the text, then republish to PDF. That way the sensitive text never exists in the PDF at all, so there's nothing underneath to recover.

Same guidance flags two other things that catch people out, and both are format-specific.

Every PDF carries automatically generated metadata: the original file name including its full path, the author's login name, and the creation date. You can see all of it under File then Properties. A file path like C:\Clients\Acme_lowball_offer\draft3.docx tells the recipient rather more than you meant to.

And Word files carry their own baggage. Editing history stays in the document when track changes has been on, which is exactly the state a collaboratively drafted contract is in. The court's recommendation there is blunt: always publish to PDF and don't hand out the original DOC. If you do need to share the Word file, run Word's Document Inspector first, under File then Info then Check for Issues, which strips comments, revisions, hidden text and personal information.

So the rule that falls out of this is a refinement of the article's main thesis rather than an exception to it. Draft in Word. Remove sensitive content in Word, properly, by deleting it. Then export to PDF and send that. What you must not do is export first and try to paint over the problem afterwards.

Which Format Should You Use for a Form People Fill In?

Word if the form is simple and everyone filling it in has Word. PDF if it's going out widely, needs a signature, or has to look the same for everyone. But there's a trap on the PDF route that catches a lot of people, and it's worth knowing before you build anything.

PDF has carried two completely different form technologies. AcroForms are the ones defined in the PDF specification itself, and they're what essentially every viewer supports. XFA is the other one, an XML-based system Adobe bolted on for dynamic forms that expand and contract as you fill them in. Plenty of government, tax and insurance forms still use it.

XFA didn't make it into the current standard. When ISO published PDF 2.0 as ISO 32000-2, XFA was left out, and the format's deprecated feature list is blunt about why that's less of a loss than it sounds: XFA forms are no longer part of PDF 2.0, and XFA was never really part of the PDF file format to begin with, more a separate format that had been attached to PDF. It's also excluded from PDF/A, the ISO 19005 archiving standard covered above, so an XFA form can't be archived in the format your records office actually wants.

The practical consequence is the part that will bite you. An XFA form is the one kind of PDF that doesn't open everywhere. Chrome's built-in viewer doesn't render it, and neither do most phone PDF apps. What the recipient gets instead is a holding message saying their PDF viewer may not be able to display this type of document, usually with a nudge to install Adobe Reader. If you've ever sent someone an official form and had them reply that it won't open, this is very often why.

So the rules are short. If you're building a fillable PDF, build an AcroForm. If you've inherited an XFA form, convert it. And if someone sends you one, opening it in desktop Adobe Reader is the route that reliably works. Our guide to editing a PDF free covers filling and annotating without paid software.

The accessibility side has its own requirements, and they're specific rather than vague. Section508.gov's guidance on forms with signature fields says to use a pro version of Acrobat, InDesign or another document development tool to add the signature field, add tooltips that match each field's label or instruction, and validate that the tab order matches the visual and logical order of the fields. A form nobody can tab through in the right order isn't a working form. Our guide to signing a PDF free covers the signing end of it.

Word forms sidestep the whole XFA mess, and they trade it for a different problem. They only behave predictably in Word, the content controls can be dragged around by whoever's filling them in, and you get back a pile of .docx files to open one at a time. That's fine for five people on your team. It's miserable for five hundred strangers.

Which Format Ends Up Smaller, and Does It Matter?

It depends on what's inside, and it matters more than people expect because the thing that stops you sending a document is almost never the format. It's the mailbox on the other end.

Start with the size question. PDF usually wins, for two different reasons. Text-heavy documents compress well and shed the revision history, comments and embedded settings a .docx carries around. Image-heavy documents shrink because exporting recompresses the pictures, while Word tends to store them close to how you inserted them. The exception is your export setting. Choose high quality print output and the recompression barely happens, so a PDF can come out larger than the Word file it came from. Same document, same software, very different result depending on one dropdown.

Two things bloat a Word file quietly. Tracked changes with a long revision history, and images pasted straight from a camera at full resolution. Both survive into the PDF if you don't deal with them first.

Now the part that actually bites. Email limits are lower than most people think, and they're set by the recipient's system rather than yours. Microsoft's own documentation on the attachment size error puts the default limit in Outlook 2013 and later at 20 megabytes, or 20480 KB, for internet email accounts, and notes it applies to the sum of all attachments rather than each file. For an Exchange Server mailbox the default is lower still, at 10 MB, and it's controlled by the maximum send size the administrator configured.

Gmail sits a bit higher and recently moved. Google announced in February 2026 that Enterprise Plus customers can attach up to 50MB, up from 25MB, with incoming messages accepted up to 70MB. That's one tier of one product. Everyone else stayed where they were.

So the practical floor is lower than any single number suggests. If you don't know what the recipient uses, assume 10 MB and you'll rarely get bounced.

What to do about it:

• Accept the changes before you export. Clearing tracked changes and comments shrinks the file and removes the revision history you probably didn't mean to send. Two problems, one action.
• Resize images before inserting, not after. Dropping a 12 megapixel photo into a document and scaling it down on the page keeps the full file inside it.
• Compress the PDF rather than the Word file. PDF compression is far more predictable, and our guide to compressing a PDF covers what each setting actually does.
• Send a link when it's genuinely large. Most systems now strip an oversized attachment and substitute a link anyway, so you may as well control which link it is.

And if a file keeps bouncing, the cause is usually one image rather than the document as a whole. Our guide on what to do when a PDF is too large to email walks through finding it.

Which Format Should You Use for Common Jobs?

The quick lookup:

On the resume question specifically, our sister site has a fuller answer alongside a free builder at IWantFreeResume.com, including how applicant tracking systems actually parse each format.

What Mistakes Should You Avoid?

Eight errors account for most of the trouble:

• Sending Word as the final deliverable. If nobody's editing it, you've handed over an editable file with your layout at the mercy of their machine.
• Losing the editable original. Keep the .docx. Converting the PDF back later is a downgrade every time.
• Printing to PDF instead of exporting. Printing flattens the structure, which strips out the tags that make a PDF accessible and searchable.
• Assuming a PDF is accessible because it's a PDF. It isn't unless someone tagged it. A scanned PDF is an image of a document, not a document.
• Using PDF for content that should be a web page. Both the UK and US governments have moved away from this for good reasons.
• Forgetting the metadata. Word stores author names, comments, and revision history, and every PDF carries the original file name and path, the author's login name, and the creation date. Check File then Properties before you send anything sensitive.
• Redacting by drawing a black box. Covering text in a PDF doesn't remove it. Delete it in the Word original and export a fresh PDF instead.
• Sending an XFA form to the general public. It's the one PDF that won't open in Chrome or on most phones. Build an AcroForm instead.

That last one catches people out more than it should. If a file is going outside your organisation, look at what's in the properties first. Our guide to password protecting a PDF free covers the other half of sending documents safely, and the digital signature guide explains how signing works once you've committed to PDF.

What Do People Ask About PDF vs Word?

Should you send a resume as PDF or Word?

Send a PDF unless the job ad or recruiter asks for Word. A PDF looks identical on every machine, so your layout survives. Some recruitment agencies want Word because they edit your details before passing it on, and a few older applicant tracking systems parse Word more reliably. When the posting names a format, use that one.

Is PDF or Word better for legal documents?

PDF, almost always. It fixes the layout, so pagination and clause numbering can't shift, and it supports digital signatures and password protection. Word is for the drafting stage, where tracked changes and comments matter. Draft in Word, then issue and archive the final version as PDF.

Can you edit a PDF like a Word document?

Not really, and that's the point. A PDF stores where each character sits on the page rather than a flowing document, so editing means nudging fixed elements. You can fill forms, annotate, and make small text fixes, but heavy rewriting means converting to Word first, editing there, and exporting a fresh PDF.

Which format is smaller, PDF or Word?

It depends on the content. For text-heavy documents the two land close together. For anything image-heavy, a PDF is usually smaller because it compresses images on export, while Word often stores them near full size. A PDF also compresses further without much visible loss, which Word files don't do well.

Is PDF more accessible than Word?

No. A well-structured Word file is usually more accessible than an average PDF, and HTML beats both. The UK Government Digital Service found PDFs are harder to find, use and maintain, and cause the most trouble for the screen readers and magnifiers people actually rely on. PDFs can be accessible, but only if properly tagged.

Sources: UK Government Digital Service, "Why GOV.UK content should be published in HTML and not PDF," 16 July 2018 (gds.blog.gov.uk); GOV.UK guidance on publishing accessible documents (gov.uk); US General Services Administration, Section508.gov, on creating accessible PDFs (section508.gov); US Department of Justice, final rule on the accessibility of web content and mobile apps provided by state and local governments under ADA Title II, published 24 April 2024, and ADA.gov first-steps guidance reflecting the April 2026 interim final rule that extended compliance to 26 April 2027 and 26 April 2028 (ada.gov); The National Archives guidance on accessibility and alternative formats (nationalarchives.gov.uk); W3C PDF techniques for WCAG (w3.org); ISO 14289-2:2024 catalogue entry, PDF/UA-2 for PDF 2.0 files, published March 2024 (iso.org); PDF Association on ISO 32000-2 and the ISO 19005 PDF/A family (pdfa.org); ISO 32000-2:2020 catalogue entry and the PDF 2.0 deprecated features list, on the exclusion of XFA forms from the standard (iso.org); Section508.gov guidance on accessible forms with signature fields (section508.gov); UK National Cyber Security Centre, macro security for Microsoft Office (ncsc.gov.uk); Microsoft Learn, macros from the internet are blocked by default in Office, including affected apps, channel versions and rollout dates (learn.microsoft.com); US District Court for the Eastern District of Tennessee, Redaction Guidance, on why black bars do not erase text, why redacting directly in PDF is unsafe, and the automatically generated PDF metadata fields (tned.uscourts.gov).; W3C, MathML specification, on representing mathematical notation so software can work with its structure; University of Washington Accessible Technology, guidance on making maths accessible, on Office Math equations carrying MathML, the limits of accessible maths support in PDF readers and assistive technology as assessed in 2026, and their recommended order of HTML page, then native Word or PowerPoint, then PDF (washington.edu). All linked above.

Got a PDF you need to shrink before emailing it? Our free PDF compressor runs in your browser, and the compression guide explains how much you can realistically save.