Can a PDF contain a virus?

What a PDF is allowed to contain besides a page

The part of a PDF that draws the page is inert. It is a list of instructions — set this font, put these glyphs at these coordinates, fill this rectangle, paint this image — and a program that follows them puts marks on a surface and stops. Nothing in that description can do anything to your computer, which is why the format has a reputation for being safe.

The format also allows a good deal more, and ISO 32000-1 defines all of it. A document may carry:

• An action that runs when the file opens, before you have done anything at all, and further actions attached to individual pages, to clicking, and even to moving the pointer over a region.
• JavaScript, held in a table hanging off the document catalogue, or attached to a form field so that a total adds itself up as you type. This is how interactive forms do arithmetic, and it is a real feature with a legitimate use.
• Other files, embedded whole. An attachment shown as a paperclip on the page, a set of files listed in the document catalogue, or a portfolio whose entire content is a collection of other documents. The PDF Association’s note on this is worth reading if you want the distinctions; the short version is that a PDF can be a container.
• Links, and actions that ask the operating system to launch something. A link is just an address written next to a rectangle on the page.
• Multimedia and 3D assets, handled by code that is not the page renderer.

Two things follow, and they matter more than the list does.

First, none of that is needed to read the document. A PDF with an open action and a PDF without one look identical, and stripping every interactive feature out of an ordinary business document costs it nothing.

Second, whether any of it happens is your reader’s decision, not the file’s. The format says what a document may contain. It does not oblige any program to act on it, and mainstream readers implement very different amounts of this — a file that does something in one may do nothing whatever in another. That is the single most useful fact in this article, and the rest of it is a consequence.

The three ways it actually goes wrong

People imagine one threat — a file with a virus in it — and there are really three, with very different shapes.

A bug in the program that opens it

A PDF reader is a parser for a large, old, permissive format, and parsers have bugs. A file deliberately malformed to trip one of them can get code running inside the reader, and this route asks nothing of you beyond opening the document. Nothing in the file need look unusual, and there is no prompt to decline.

This is the route that argues for keeping your reader updated, and for preferring one that runs inside a sandbox. It is not a reason to avoid PDFs; it is a reason to care which program you hand them to.

You are persuaded to do something

The document is a leaflet. It says your invoice is attached, or your account needs attention, and it carries a link — or a QR code, which is a link you cannot read before following. You follow it, you arrive somewhere that looks right, and you type a password.

Nothing in the file is malicious here. There is no code, no exploit and no script; every byte of it is an ordinary document. This is the route that needs no cleverness at all, and it is the one nothing can be scanned out of, because there is nothing there to find. A link inside a PDF deserves exactly the suspicion a link in an email gets, and for the same reasons.

Active content the reader will genuinely run

The narrowest of the three, and the one people worry about most. A script in a PDF has nothing like the reach a macro in an office document has, mainstream readers do not run launch actions without asking, and a browser’s built-in viewer implements only a small part of the interactive model in the first place. It is not nothing — a script can rewrite the page you are looking at, or push you towards a link — but a document that needs you to agree to something before it works is a document that gave you a chance to decline.

The prompt is the tell. Enable this content. Allow this document to connect. This file is protected — click to view. A document that has to ask is asking for a reason.

Opening one you are not sure about

In rough order of how much good it does:

1. Update your reader, and stop there if you do nothing else. The exploit route is the only one you cannot decline, and a current reader is the whole defence against it. This applies to browsers too — the built-in PDF viewer is updated with the browser.
2. Open it in a browser first. A browser’s viewer is a separate implementation of the format, it runs inside the sandbox the browser puts web content in, and it does not have your documents and settings in front of it the way a desktop application does. It also implements far less of the interactive model, which here is a feature. A sandbox is a reduction in exposure and not a guarantee, but for an unexpected attachment it is a better first look than double-clicking.
3. Do not agree to anything. No enabling, no allowing, no trusting the document. If the file will not show you its contents without permission to do something, you have learned what you needed to know.
4. Treat every link in it as a link from a stranger. Read the address before following it. If it wants you to sign in, do not sign in from the link — go to the site the way you normally would and look for the same thing there. This is dull advice and it is the advice that works.
5. Leave attachments alone. A paperclip icon on the page is a file from whoever sent the PDF. Opening it is opening an attachment, with all of that risk and none of the PDF format’s inertness.
6. If you only need the words, take only the words. PDF to text reads the file with PDF.js in your own browser tab and hands back the text; the document is never opened interactively and no action in it is followed. It runs in your browser, so the file is not uploaded — how browser PDF tools work covers how to verify that for yourself.

And the one that has nothing to do with PDFs: if the document is about money, credentials or an urgent change of bank details, confirm it through a channel you already trust. That is not a technical control and it is the one that actually stops the loss.

What this site can and cannot tell you about a file

Plainly: iBuildPDF has no malware scanner, and no tool here reports whether a PDF contains a script, an open action or an embedded file. That is worth saying rather than implying, because a site full of PDF tools is exactly where someone would expect to find one.

What the inspection tools do report, and nothing more:

• Page count and file info — the page count, the file size, the page dimensions in millimetres with a count of each, portrait against landscape, and whether there is a text layer at all. The text check samples the first twenty pages rather than reading every one, because for the question it answers twenty pages is decisive and a nine-hundred-page document still answers instantly.
• The metadata editor — the title, author, subject, keywords, and which application recorded itself as having produced the file. That last one is often the most informative thing about a document, and it is also a field anyone can write anything into. What PDF metadata contains goes through it.

There is one side effect worth knowing about and not worth trusting. Nearly every tool here builds a new document and copies the pages into it, for a reason that has nothing to do with security: the PDF library this site uses mishandles a source that has been saved as an incremental update, and writes a file Acrobat then refuses to open. A rebuild starts from an empty document catalogue, so things that lived in the old one — the open action, the document-level script table, embedded files — are not in the output.

Do not read that as cleaning a file. Annotations belong to the pages and are copied with them, links included. The tool is not looking for anything, so it cannot tell you whether there was anything to find. And the file you started with is still sitting on your machine. If you genuinely suspect a document, the right instrument is antivirus or endpoint software built for the job, or a sandboxed analysis service. This is a set of document tools, and a document tool that implied otherwise would be the most dangerous thing on the page.

If you are the one sending it

Most of the trouble on the receiving end is created, without any intent, by ordinary senders.

• Do not build a document that has to ask for permission. If your PDF needs a script to display its own contents, some recipients will see nothing and the rest have been trained to refuse.
• Do not send a PDF whose only content is “click here to view the document”. That is the exact shape of a phishing lure, mail filters treat it as one, and the people who notice will not open it. Send the document.
• Flatten a completed form before you send it. Flatten PDF writes the field values into the page, so nothing needs to be live for the recipient to see what you typed — and a filled form that arrives blank is a whole separate afternoon. How PDF forms work and what flattening does cover the mechanism.
• Send attachments as attachments. A spreadsheet embedded inside a PDF is harder to reach, more likely to be stripped in transit, and more likely to be refused by whatever the recipient uploads it to. Why an upload form rejects your PDF covers that last one.
• If it needs a password, send the password another way. Both in the same message protects nothing. Protect PDF can apply one, and it runs on a server, so the document is uploaded to be encrypted; what a PDF password actually protects is worth reading before you decide it is the control you want.

Last, the thing a sender can do that helps most: say what you are sending, in the message, before the attachment. A recipient who was expecting a document does not have to guess, and guessing is where all of this goes wrong.