PDFs on your site: when to offer one and how to label it

Only offer a PDF for something people will print or keep, and always as a copy of an HTML page that already covers the essentials. The link to the file should say it’s a PDF and show the page count and file size, so people can decide before they click (NN/g, Avoid PDF for On-Screen Reading). For reading on screen, a regular page works better.

Why PDFs get in the way on screen

PDF was made for paper. Each page is sized like a sheet, not a window, so on a phone people have to zoom, drag and hunt for where they were (NN/g, PDF: Still Unfit for Human Consumption). That 2020 article pulls together twenty years of testing and lands where Jakob Nielsen’s original piece from 1996 did.

The problems NN/g keeps seeing in tests (NN/g):

No navigation. The file doesn’t have the site’s menu, and a clickable table of contents doesn’t fix it: people still scan headings until they find the part they need.
Slow to open. In one study, a cafeteria menu in PDF took almost 3 minutes to download.
Disorienting. If the file opens in a new tab and nobody notices, the Back button seems broken. If it opens in the same tab, people close the window thinking it was a new one and lose their place.
Goes stale quietly. Old versions stay online with links still pointing at them, and anyone who finds one starts doubting the rest.

When a PDF makes sense

NN/g’s rule of thumb is short: PDF is for documents that will be printed (NN/g). An annual report, assembly instructions, a form that needs a signature or a résumé someone attaches to a job application all fit.

Even then, the file shouldn’t be the only format. The advice is to check first whether your audience actually prints, because many people who get a PDF only wanted to read one part on screen (NN/g).

The page comes before the file

NN/g’s answer is a gateway page: an HTML page that sums up what the document says and offers the full file as a download (NN/g). Anyone who only wanted the answer gets it there. Anyone who needs the whole document downloads it knowing what they’ll get.

That page is also the one that should show up in site search and on Google, not the bare PDF. NN/g notes that big files tend to rank high in internal search because they repeat the searched words so often (NN/g). People click and land on page 47 of a document that only mentions the topic in passing.

What the link should say

A link to a PDF should show three things right next to it: that it’s a PDF, how many pages it has and how big it is (NN/g). That way people can tell whether it’s worth their mobile data and their time.

The same guide lists what to get right in the file itself (NN/g):

Keep it light. Shrink images and cut what doesn’t need to be there.
Make it accessible. Selectable text, structure tags for headings and tables, a set reading order and alt text on images.
Fit both paper sizes. The US uses Letter, while Brazil uses A4, which is a little narrower and taller. The document has to fit on both.
Don’t leave old versions up. Take down the previous one and update the links. If it has to stay, say on the first page which version is current.

Download, same tab or new tab

There’s no single rule. NN/g’s article on new tabs says that on desktop, people in their studies usually checked the PDF alongside the page it came from, or printed it. So there, opening it in a new tab worked better (NN/g, Opening Links in New Browser Windows and Tabs). On mobile, the advice flips: if you can’t avoid the PDF, open it in the same tab, because getting back is easier.

For files people will edit, like spreadsheets or slide decks, the same article prefers a direct download, so they can open them in whatever app they use (NN/g). Whatever you choose, tell people before they click when a link opens a new tab.

What the code controls

In HTML, the download attribute on the <a> element tells the browser to save the file instead of opening it. Given a value, it suggests the saved file’s name (MDN, the Anchor element). It only works for files on the same origin as the page. For a PDF hosted somewhere else, the browser ignores it and just follows the link.

The server gets a say too, through the Content-Disposition header. When it says inline, meaning show it on screen, MDN explains that the download attribute wins and the file is downloaded (MDN). The file name sent by the server, though, wins over the name in the attribute.

The type attribute, set to application/pdf, only hints at the format and doesn’t change anything about how the browser behaves (MDN).

PDFs end up in search too

Google reads and indexes PDFs like any other page (Google Search Central, file types indexable by Google). That’s good when the file is the only source, and bad when there’s a gateway page and search sends people straight to the PDF.

Since a PDF has no <head>, a noindex meta tag can’t go in it. The way to do it is the X-Robots-Tag: noindex response header, which Google supports for non-HTML resources (Google Search Central, block indexing).

How I did it on kahue.net

The site got a PDF résumé on October 30, 2026, one file per language. The “Download CV (PDF)” link sits at the top of the home page and the about page. The about page is the HTML version, with experience, education and certifications, and the PDF is the copy to attach to an application.

All three files come from one script, scripts/gera-cv.mjs, which builds the document from the same data that feeds the page. So the PDF doesn’t fall behind when a role changes, which is the stale version problem NN/g describes. Each file name is fixed, like kahue-morais-en.pdf, so the link doesn’t change with each new version.

In the code, the link has download with the file name and type="application/pdf". The server replies with Content-Disposition: inline and the same name, so the names don’t clash. The Portuguese file is 4 A4 pages and 142 KB, the English one is 3 pages, and all of them come out with structure tags.

Going by NN/g’s guide, three things are missing. The link says it’s a PDF but doesn’t show pages or size. The file has no X-Robots-Tag: noindex, so it could show up in search instead of the about page. And the layout was only designed for A4.

Where the sources disagree

NN/g itself doesn’t settle the direct download question. The PDF guide says downloading can spare people from reading the file in the browser, but some are annoyed at having to open it afterwards in another app (NN/g). Both articles end up saying to test with your own audience.

The documentation also differs across languages. The Portuguese version of MDN still says that with inline, Firefox follows the server and opens the file (MDN (in Portuguese)). The English version, which is newer, says the attribute wins (MDN). The Spanish version explains the gap: only Firefox before version 82 followed the server (MDN (in Spanish)).

The common mistake: posting the PDF instead of the page

The most common slip is getting a finished document and uploading the file as if it were the page. NN/g tells of an intranet team that kept hearing the same request: someone would hand over a PDF and ask for it to go online (NN/g). It feels faster, but every later fix means finding the original, making a new file and swapping the links.

Writing the page first takes the same content planning. The difference is that a fix becomes a single edit, and the PDF goes back to being what it should be: a copy for printing.