Summary — Deploying PDFs in a publishing workflow may save the author time and effort, but comes at the cost of requiring too much effort of the reader. With rare exceptions, it’s not worth this trade-off.
When it comes to publishing on the web, PDF files are rarely the answer. “PDF?” is the question. “No” is the answer. Almost always.
For every complex problem there is an answer that is clear, simple, and wrong.
Are there appropriate uses for PDFs online? Sure. Maybe. But that expensive, glossy, fold-out, 4-colour printed brochure you had produced? Of course you want to repurpose it — because you’re proud of it and it serves a purpose — but no one can make any sense of it on a smartphone (probably half of your visitors), and no one — no one — is excited to print it out at home.
The thinking behind posting PDFs on websites is completely understandable — everyone wants their job to be easier, and everyone wants their website to be as useful as it can be with as little time/effort/training/expense as possible. Click the little “PDF” icon in Microsoft Word and move on, right?
Not so fast.
Punting to PDF shifts the effort to your visitors. It literally makes your site harder for people to use. Other people are just as busy as you are, and if you force them to take the time to sort out your publishing issues, I just don’t care is a likely response.
Points of failure for PDFs on websites:
- Failing to compress the PDF for fast download (time is money and cellular data is expensive)
- Publishing a PDF formatted for letter-sized paper (or larger) that can’t be easily read or navigated on a phone
- Presuming that people have access to a printer
- Presuming that people are motivated enough to take the time and expense to print your PDF
- Presuming that your beautifully-designed full-colour PDF is still legible when printed on a black-and-white laser printer
- Naming the PDF poorly (so it can’t be found later)
- Linking to it poorly/confusingly (so people don’t know what kind of file they’re dealing with)
- Choosing to publish a PDF in the first place.
Ok. Despite all of this, you published your PDF anyway (because converting it to HTML would’ve involved hassle/expense/delay). Now what?
- What happens next? The file may download to the user’s desktop or downloads directory on a desktop operating system (meaning they have to go find it and open it); it may open directly in the browser; it may open in 3rd-party software (some version of Adobe’s Acrobat Reader (or whatever they’re calling it this month) or Apple’s Preview app); some will find this trivial, others will have no idea what to do. Either way, providing instructions on this is not straightforward and is almost certainly beyond the scope of your website.
- You make them search again — the keyword search on your site (or on Google) that brought them to PDF won’t help them find the content they’re after inside the PDF
- You make them wait and/or cost them money — the PDF was print-optimized, so it’s 230 MB (with no warning). Mobile users on slow, pricey data plans (a group otherwise known as people with cell phones) will not appreciate this.
- You hand them a filing task — the PDF was generically named “
June Newsletter.PDF” — stripping it of useful context once it’s been downloaded (there’s no date, organization name, or topic in the filename); worse, the filename exposes your internal editing/revision/approval process (“
final newsletter draft rev. 3 final (revised).pdf”).
- You’ve turned getting the file into a multi-step task for the visitor — mobile operating systems, in particular, can be confusing when it comes to downloading and saving files.
- There was no warning that it was a PDF; in the worse possible case, the link was some variant of “click here…” (see also ‘Your site can use “Click here” links or it can be easy to use — pick one’).
- Spaces in the PDF’s filename may be rendered as
%20, so what people see when they preview your link is “
June%20Newsletter%20final-revised2.PDF”; this is unfriendly at best.
This poor visitor to your website already had 137 things to do and just wanted to know what time that thing was tomorrow.
Really, this is just one tiny example of how thinking things through from the perspective of your website’s visitors can improve their experience with your organization.
Why does this matter?
The way to make a site easy to use is by sweating the details; it’s not a lot of work, but it does take some thought. This battle is fought by asking yourself is there a better way to get this out there than just uploading a PDF — and if uploading a PDF is the answer, then how can I make it as painless as possible?
Some parting thoughts:
- Terrible, hard-to-use, frustrating websites are made of tiny decisions in the form of screw it, I can just post this PDF and move on.
- Websites that need to be burnt to the ground every 3–5 years are slowly built through all of these little choices. This is economically unsustainable.
- If you can’t (or choose not to, or haven’t the time to) empathize with those who want or need your website, find someone who does.
- Websites need champions. They need advocates. They need passion. They don’t need glitzy slide-shows, more social media sharing icons, benign neglect, or bigger logos.
The answer is almost always to convert the contents of your PDF publications to HTML, where they can serve everyone — regardless of the size of the screen they’re using.
- PDFs: We need to talk — How to spot and counter the most common excuses for publishing PDFs on the web. This May, 2018, post by Dan Craddock makes some excellent points about the time/effort/expense arguments against converting to accessible HTML instead of taking the lazy, inaccessible way out. Yes, I know; it’s Medium. Still.