How to Remove Hidden Scripts from a PDF
PDF files can carry JavaScript, launch actions and embedded files that run on open. Here is how to inspect a file and strip the dangerous parts.
NewKitApp 9 min read
A PDF looks like paper, and paper is inert. The file format is not. A PDF can contain small programs, actions that fire when the document opens, attached executables, and hidden layers of data the visible page never shows. Almost every PDF you meet carries none of this in a hostile way. The ones that do are why security teams treat attachments from strangers as live objects until proven otherwise.
This guide explains what can hide inside a PDF, which parts can act on your machine, how to inspect a file before trusting it, and how to strip the active parts while keeping the document looking exactly the same. Every tool named here runs in your browser; nothing gets uploaded.
What a PDF can carry besides visible content
JavaScript. The PDF standard includes a scripting language, a relative of the one websites use. Honest uses exist: forms that add a column of prices, documents that show or hide sections on a click, dynamic stamps with dates. Malicious uses follow the same mechanics: scripts that fire on opening, that rewrite the document, that quietly submit form data to a distant server, that chain into other weaknesses of old viewer software.
Automatic actions. A document can define an OpenAction, an instruction the viewer runs the moment the file renders. Usually it just jumps to a page or sets the zoom. It can also call a script. Page actions and annotation actions extend the same idea to other moments: when a page becomes visible, when a link is clicked. The historic nasty variant, the Launch action, asked the viewer to run an external program; modern viewers block it by default, but the instruction still sits in files from earlier decades.
Embedded files. A PDF is a container, and containers carry attachments: spreadsheets, images, executables. An attachment by itself does nothing. Combined with an action or a plausible social-engineering line of "open the attached statement", it becomes the delivery mechanism.
Hidden text and metadata. Text can sit outside the visible page area, white on white, or under an opaque cover. Metadata fields carry author names, editing histories, software versions. None of this executes. It leaks information instead, and it matters for a different reason: redacting by drawing a black box over words hides nothing, because the words are still in the file, selectable and searchable. True redaction removes them.
Layers and optional content. Sections that viewers can show or hide. Mostly a design feature for engineering drawings; occasionally a trick where the printed page differs from the displayed page.
The pattern in the list: half of it is about code that runs, and half is about data that lingers. Sanitizing addresses the first half. Metadata cleaning and proper redaction address the second.
What the scripts can actually do
Scripting inside a PDF runs in a cage. It can manipulate the document, dialogs, form fields, and make limited network requests, depending on how permissive the viewer is. It cannot freely read your filesystem the way a regular program can.
The real danger historically came from the cage being badly built. Viewers that parse malformed PDFs have been a reliable source of vulnerabilities for two decades, and a crafted file that crashes a viewer parser can sometimes break out of the cage entirely. The script and the malformed structure work together: the document looks like an invoice, the parser stumbles over a specially folded object, and code runs with your privileges. Antivirus vendors have catalogued these campaigns for years; the famous ones shipped as email attachments named like invoices, resumes, and shipping notices, which is exactly the social pattern still in use.
Modern viewers are far more defensive than their ancestors. Sandboxes are real, JavaScript can be disabled entirely in desktop readers, and unsigned nonsense usually fails to open. The lesson is not that PDFs are safe by default. The lesson is that a file from an untrusted source deserves inspection before it gets clicked open on a machine that matters.
Inspecting a file before you trust it
The PDF security checker on this site reads the file locally and reports what is inside: whether JavaScript is present, whether the document defines open or launch actions, whether it carries embedded files, whether it is encrypted, and what the structure looks like. It computes a fingerprint of the file so you can compare it against a known-good copy, and it lists its findings in plain language.
Reading the report takes seconds and answers the question that matters: does this document contain anything that acts, or is it just pages?
A few findings deserve context. "JavaScript present" on a government form that calculates totals is normal. "Encrypted with an owner password" on a file from your bank is copy-protection, not an attack. "OpenAction present" alone means the document sets its initial view, which nearly every exported PDF does. The checker distinguishes the benign forms of each from the suspicious combinations: scripts plus network submission, actions that call scripts, embedded executables, structure that resembles known exploitation patterns.
Stripping the active parts
The PDF sanitizer removes what can act while preserving the visible document. It deletes document-level and inline JavaScript, strips OpenAction and Launch and other automatic actions, removes embedded attachments, and drops form submission and data-collection instructions. Pages, text, images, and ordinary annotations survive untouched: the sanitized file shows the same content and prints the same output. If you want the file locked afterwards, run it through the protector to add a password.
The workflow takes under a minute. Open the sanitizer, drop the file, review what it found, choose what to remove, and download the clean copy. For a file you received from outside and need to forward, archive, or open repeatedly, sanitizing first is cheap insurance.
Three habits cover most real situations:
You received a PDF from an unknown source. Run the checker first. If the report is clean and you expected the document, read on. If anything active shows up, either delete the file or sanitize a copy and open that.
You distribute PDFs to other people. A newsletter, a form, a report going to clients. Run your own file through the sanitizer before sending. Your readers get the content with the machinery removed, and nobody's viewer ever has to decide whether your form script is friendly.
You archive documents for the long term. Active content decays badly: viewers tighten their rules, scripts stop working, attachments get stripped by gateways. A sanitized, flattened document is the stable artifact. Archives worldwide standardize on exactly this kind of quiet file.
What sanitizing does not remove
Honest limits keep expectations correct.
Sanitizing keeps metadata. Author, title, creation software, and timestamps survive, because removing them is a different operation with different intent. If a document's history should not travel with it, clean the metadata separately with the metadata editor.
Sanitizing does not redact. Drawing a black rectangle over a paragraph leaves the paragraph in the file. Proper redaction removes the text and its structure, which the redaction tool does, including the classic trap of text hidden under cover rectangles.
Sanitizing does not verify content. A document can be perfectly inert and perfectly fraudulent. The invoice with no scripts still asks you to pay it; the resume with no attachments still lies about its author. Code is one risk; claims are another.
And sanitizing cannot fix a file that exploits the viewer's parser from malformed structure alone. Well-formed-looking files crafted to crash parsers are the rare case where the right answer is to not open the file at all, on any machine, and the checker's structural findings are the hint that you are holding one.
A worked example
Concretely, say a supplier emails a "purchase order update" you did not expect. You need the numbers on it, and you need to open something.
Run the file through the checker first. The report comes back in seconds: 2 pages, no encryption, an OpenAction that calls a document script, JavaScript present, one embedded file with an executable extension, and a submission URL pointing at a domain registered eleven days ago. Every single finding has an innocent explanation in isolation; the combination reads like a delivery.
You have two moves. Delete the file and ask the supplier through a channel you already have, which is the right call for the executable alone. Or, if you genuinely need the visible content, sanitize a copy: the script, the action, the attachment, and the submission instruction disappear, and what remains is a two-page document with the numbers you needed. You never ran the original on a machine that matters.
Now flip the roles. You are the supplier sending invoices to hundreds of customers. Your template has a script that formats totals, added by a predecessor who left in 2021. Every one of your customers' security gateways examines that script. Sanitizing your outbound file removes the question entirely: your customers receive pages, not programs, and your invoice stops tripping anyone's scanner. Outbound hygiene turns out to matter as much as inbound caution.
Where the dangers actually came from
A little history calibrates the fear correctly.
Through the 2000s and 2010s, crafted PDFs were a top-tier attack vector because desktop readers ran with generous permissions and buggy parsers. Documented exploits chained malformed fonts, image decoders, and script engines; security firms recorded entire toolkits that generated malicious PDFs on demand. The industry response reshaped the landscape: viewers moved to sandboxed processes, disabled risky features by default, and rewrote parsers defensively.
Two consequences matter today. First, a patched modern viewer defeats the overwhelming majority of historical attacks, so the panic sometimes attached to PDFs is dated. Second, attackers moved up the stack: instead of breaking the cage, they now mostly rely on social engineering, attachments that trick you into opening something outside the PDF, or phishing pages the document links to. Which is why this guide spends as many words on inspection habits as on the technical stripping.
The file format also matured. Current PDF standards separate the archival profiles used by libraries and agencies, which mandate quiet, self-contained documents with no active content. When you sanitize a file, you are moving it toward exactly that profile: the boring, stable kind of PDF that survives decades and hostile networks.
Frequently asked questions
Do all PDF readers run JavaScript? Desktop readers from the major vendors support it, usually with a setting to disable it. Browsers' built-in viewers mostly ignore document scripts, and the in-browser tools on this site never execute PDF scripts at all: the engine renders pages and skips the machinery entirely.
Can a PDF infect my computer just from being previewed? Modern preview surfaces are hardened, and drive-by compromise from a mere preview is rare today. The historic pattern needed a vulnerable viewer plus a crafted file plus usually some interaction. Rare is not never, which is why inspection before opening is the habit.
Is a PDF from a big company automatically safe? Reputable senders produce clean files, and spoofing a big brand is free. Judge the file, not the logo on it, whenever the document arrived uninvited.
What is the difference between sanitizing and password-protecting? Protection controls who opens the file. Sanitizing controls what the file contains. They combine well: sanitize, then protect, for a clean and locked document.
Does sanitizing change how the document looks? The visible pages are preserved. Interactive features that relied on scripts, like a form that totals itself, stop totaling; the fields and their contents remain.
The short version
Treat an incoming PDF as a claim, not a fact. Check it: the security checker reads the file locally and tells you whether it carries scripts, actions, or attachments. Clean it when needed: the sanitizer strips everything that can act and keeps everything you read. Keep the habits separate: metadata leaks are an editor's job, hidden words are redaction's job, and fraud is your judgment's job. The paper metaphor made you think the file was inert; now you know which parts of it are not, and what to do about them.