PDFs default to "the polite way to send a document". That's often right, sometimes wrong, and occasionally hostile to the recipient. This post is the decision tree I wish I had a decade ago: when a PDF is the best answer, when a link is, when an image is, and when plain text would have saved everyone time.
What each format is actually good at
Quick reference. Each format is best at one job and worst at one job:
| Format | Best at | Worst at |
|---|---|---|
| Fixed layout that prints predictably | Phone reading, editing, accessibility | |
| Web link | Always-current, searchable, indexable | Offline reading, archival "this is what I sent" |
| Image | Phone-friendly, single page, social | Editable content, copy-paste, accessibility |
| Plain text (email body, Markdown) | Quick reading, copy-paste, archive | Layout, branding, multi-page |
Mapping a situation to a row gives the obvious answer most of the time. The rest of the post is about the edge cases.
The defaults I actually use
Six patterns covering 80% of business communication:
A multi-page contract that needs to be signed
PDF. Signatures require pixel-stable layout. PDFs print, sign, scan back consistently. A web link doesn't help when the lawyer needs to mark up a printed copy.
A long-form article you wrote
Web link. A page on your own site is indexable, copyable, shareable as a single URL. Sending the same text as a PDF strips it of all those properties. The only reason to PDF an article is offline distribution where the reader explicitly wants a printable file.
A single chart or screenshot
Image. PNGs and JPEGs render instantly on every device, including weak phone browsers. Wrapping a screenshot in a PDF adds an open-this-app step for no gain.
A short status update
Plain text in the message. The number of business emails that contain a one-paragraph PDF attachment is staggering. The recipient has to download, open, read, then come back to the email thread. Just put the paragraph in the message.
A recipe, a menu, a how-to
Markdown rendered to HTML on a page. Web-native, copy-paste-friendly, can be updated when prices change or steps improve. PDF is what you produce when the content is final; living content shouldn't be PDF.
An invoice
PDF. Fixed format, archives well, every accounting system on Earth knows what to do with a PDF invoice. Web links break when the invoice service shuts down five years later; the PDF is the durable artefact.
When PDF is the wrong default
Three places PDFs are commonly used but shouldn't be:
Anything that will primarily be read on phones
PDF pagination is designed around paper. On a phone, the reader has to pinch-zoom, swipe, scroll-zoom, fight reflow. A web page with responsive CSS reads ten times more comfortably on a 5-inch screen.
A useful test: open your PDF on your own phone, in portrait orientation, before sending it. If you can't read body text without zooming, the recipient won't either.
Forms that will be filled and returned
Fillable PDF forms exist; most people don't know how to fill them. The common workflow is "print, fill by hand, scan, email back". That's three roundtrips that an HTML form skips entirely.
If you need structured data back, use a form. If you need a signature, use an e-signature service. PDF forms are the worst of both worlds for everyone except the small minority who run Acrobat Pro.
Content that will need updates
PDF is immutable from the recipient's perspective. If the menu prices change next month, every person you sent the menu PDF to has stale pricing. A link to a page that updates is the right tool. Generate a PDF only if someone explicitly needs an offline copy.
When images beat PDFs
Three scenarios:
A single page or section of a longer document
A PDF reader is overhead for one page. Send a JPG or PNG of just the relevant page. The reader needs no extra app, can save it to their photo library, can quote it inline in a chat.
The PDF to JPG tool does this in one step — drop the PDF, pick the page (or all of them), download the JPG.
Social-media or chat sharing
Twitter/X, Slack, WhatsApp, LinkedIn all preview images instantly. PDFs require clicks. If your one-page summary is going to land in a feed, ship the image.
Visual content where copy-paste of text isn't needed
A screenshot of a quote, a meme, a diagram, a marketing card. PDFs are overkill; an image is the native format. Use the Image Resizer to right-size before sharing.
When plain text beats everything
If the content fits in a paragraph and is mostly words, just send the words. Five lines of context in the email body beat a "Q3 update — please see attached" PDF every time.
A useful litmus test: would a screen-reader user (yours or a colleague's) prefer your attachment or the equivalent paragraph? Plain text and Markdown are accessibility-perfect by default. PDFs are accessibility-difficult by default and only good when explicitly tagged for it.
If you want light formatting — bold, lists, links — write it in Markdown and either paste it as-is (most email clients now render it) or render it to HTML for embedding. Our Markdown Preview tool can show you what the output will look like before you ship.
Hybrid: PDF + an editable source
For content that's both a final artefact and likely to be edited, attach both: the PDF for "this is the version I'm sending now" and the source (.docx, .md, .pages) for "if you need to edit, here's how". This is common in legal, design, and academic workflows.
A few cautions:
- Make sure the two are actually in sync. Sending an outdated .docx alongside the current PDF causes confusion every time.
- The .docx may carry comments, change tracking, hidden columns, and metadata you stripped from the PDF. See PDF metadata: what your file is telling people — the same risks live in Office documents.
- Embedded files inside the PDF (Acrobat's "Attach" feature) are often missed by less capable readers. If both files matter, send them as separate attachments.
The shipping decision in one sentence
If the recipient will read, copy, search, share, or update the content, default to a link. If the recipient will print, sign, file, or archive, default to a PDF. Everything else is an image or plain text.
Workflows that actually work
A few real combinations to copy:
- Sales proposal → PDF for the contract part, web link for the supporting case studies, plain text in the email summarising the offer.
- Conference talk → web link to the slide deck (or a recording), PDF backup for offline conferences, image of the title card for social sharing.
- Recipe blog post → web page (canonical), printable view (PDF on demand for kitchen use), image for Instagram.
- Internal policy document → web page on the intranet (updates as policy changes), PDF snapshot per version for compliance archive, plain-text summary in the email announcing the change.
- Customer invoice → PDF (the artefact), web link to a portal where the invoice can be paid (the action), plain-text "your invoice is ready" email.
Each one uses two or three formats, each playing to its strengths. The mistake is treating one format as the default and forcing every situation into it.
Tools that help
- PDF Merge and Split PDF — assemble or break apart a PDF when the format is the right choice.
- PDF to JPG — extract a page as an image when the content is better shared visually.
- Image Resizer — right-size an image before sharing so the recipient doesn't download 8 MB unnecessarily.
- Markdown Preview — see what your plain-text-with-formatting will render as before pasting it into an email or doc.
The format is part of the message. Picking the right one is a small act of respect for the reader's time and attention.