How to check a PDF for malware without uploading it

No browser can run a virus scanner, and anybody telling you otherwise is selling something. What a browser can do is read the PDF's own structure and tell you whether it contains the parts a weaponised PDF needs: JavaScript, an action that runs the moment the file opens, a launch action that starts another program, and files embedded inside it. Most ordinary PDFs contain none of those. X-RAY reports them and lists every web address the document points at, without opening the document and without uploading it; DISARM removes them and tells you what it took out. Neither is antivirus, and the sections below are as much about what this does not settle as what it does.

Three different things people mean by a dangerous PDF

Almost every answer to this question treats "is this PDF safe" as one question. It is three, they need three different checks, and only one of them is what a signature scanner is looking for.

Knowing which of the three you are facing is most of the answer. A structural check settles the first completely, helps with the second, and says nothing at all about the third.

Why the standard advice is to upload it, and when that is wrong

Search this question and every result says the same thing: upload it to VirusTotal. That is good advice for a file that is not confidential, and this site does not replace it: a signature check against seventy engines answers a question no structural reader can, namely whether anybody has seen this exact file before and called it bad.

But it is worth knowing what an upload is. A standard VirusTotal submission is shared with the participating security vendors and with organisations paying for its threat-hunting service, who can search for and download it. VirusTotal maintains a documentation page about what to do if you uploaded something confidential by accident, which tells you how often that happens. They also sell a private scanning tier precisely because the ordinary one shares.

So the question to ask first is not "is this file suspicious" but "whose file is this". An invoice, a contract, a witness statement, a medical letter, a client's disclosure bundle: these are documents you cannot put into a sharing ecosystem to answer a question you can answer another way.

What to check, in order

1. Is it even a PDF. The extension is a claim, not a fact. X-RAY reads the file's own first bytes, so a program renamed to .pdf, or the double extension invoice.pdf.exe that Windows will happily hide half of, does not survive the first line of the report.
2. Does it contain active content. Four flags: JavaScript, an OpenAction that runs on open, a Launch action that starts a program, and embedded files. A document that is genuinely a document usually has none. A form might have JavaScript for validation, which is legitimate; the point is to know it is there.
3. Where do its links go. X-RAY lists the addresses the document points at, which lets you read a link without clicking it and without hovering over it in a reader that might act on the hover. A "view your invoice" button pointing at a domain registered last week is the whole attack, and no scanner will flag the file.
4. Take a hash first, if this might matter later. CHECKSUM takes a SHA-256 of the file as it arrived. If it turns out to be something worth reporting, the first question you will be asked is whether the copy you examined is the copy you received, and a hash taken before you touched it is the only convenient answer.

What a real finding looks like

A PDF built with a script, an action that runs on open, and a file hidden inside it produces this, and nothing about the file is opened to get it:

Run the same file through DISARM and it reports what it removed, item by item (open action, document JavaScript, embedded files), and writes yourfile.disarmed.pdf, which still shows every page. That is the version to open if you need the document at all.

What to do about each answer

• Active content, and you were not expecting the file. Do not open it. The finding is not proof of anything, but an unexpected attachment with a script in it is not a document you need.
• Active content, and you do need the document. Run it through DISARM and open the cleaned copy. Read what it says it removed: an invoice with an embedded file and a launch action in it is worth a phone call to the sender on a number you already had.
• Nothing active, and the links go where they claim. Open it in your browser rather than in a desktop reader. Chrome, Edge, Firefox and Safari draw PDFs in a sandboxed process with a far narrower scripting surface than a full reader, and none of them will run a launch action. It is a reduction in risk, not an absence of one.
• Nothing active, and the file is not sensitive. Then upload it to VirusTotal as well. The two checks answer different questions and there is no reason to pick one.

Why finding nothing settles less than it seems

This matters more than anything above, and it is the part that gets left out.

A structural check finds structure. It does not find a link to a page that looks exactly like your bank, because there is nothing wrong with the file: the attack is the text and the address, and both are ordinary. It does not find a malformed font or a broken image stream crafted to corrupt memory in whatever program renders it, because that PDF is, structurally, a perfectly normal PDF with a picture in it. Those are real attacks and they have nothing for this to report.

So "no active content" means the file does not contain scripts, open actions, launch actions or embedded files. It does not mean the file is safe, and it should never be written up as though somebody cleared it. Keep the renderer patched, prefer the sandboxed one, and treat an unexpected attachment as unexpected however clean it reads.

The same applies to Word and Excel, for different reasons

Office files carry a wider set of active parts: VBA macro projects, ActiveX controls, embedded OLE objects, DDE and INCLUDE field codes, and remote templates that fetch content from an address the moment the document opens. DISARM removes all of those too, writes a macro-enabled file back as the plain format, and lists each removal. A .docm that arrives claiming you must enable content to read it is the oldest attack still working, and there is no version of enabling it that is the right move.

The same two-step applies. MACROLENS reads the VBA out of a .docm, .xlsm, .doc or .xls without opening it in Office, so you can see what the macro would have done before deciding, and DISARM removes it. A macro that fetches a file from an address and runs it reads exactly like that, in plain sight, and takes a minute to find.

And one format that is not on anybody's list because it looks like a picture: SVG is a document, not an image. It can carry <script>, event handlers and references that fetch from a remote address the moment it is rendered. A browser will run all of it. SVGCLEAN strips those and leaves only what draws, which for an SVG somebody sent you is worth doing before it is opened anywhere that matters.

Alongside: STRATA recovers the earlier versions a PDF saved by appending still carries, which is a different question about the same file, and CHECKSUM records which file you actually looked at.