PDF Tracking Checker
Scan a PDF for tracking risks — external URLs, JavaScript, auto-actions, embedded files and form-submit URLs. 100% local, no link is ever fetched.
Quick answer: Drop a PDF and we read it locally with pdf.js plus a raw byte scan, then list every external URL, /JavaScript or /JS action, /OpenAction or /AA auto-trigger, /SubmitForm, /Launch, embedded file and Web Capture marker. You get a Clean / Low / Medium / High risk badge and a per-check breakdown — and crucially, none of the URLs we surface are ever fetched.
Last updated
Frequently asked questions
- What does the PDF Tracking Checker look for?
- Eight categories: external http(s) URLs, JavaScript actions (/JS, /JavaScript), auto-trigger actions (/OpenAction, /AA), form-submit actions (/SubmitForm), Launch actions (/Launch), remote-document links (/GoToR, /GoToE), embedded files / attachments, and Web Capture metadata (/SpiderInfo). It also flags XFA dynamic forms and /RichMedia content.
- Does the checker actually open the URLs it finds?
- No. That's the whole point. We list every URL inside the PDF, but we never make a single network request to any of them. Open DevTools → Network and watch — you'll see no requests fire when a PDF is scanned. Your IP, the PDF and any tracking pixel destinations stay private.
- What are 'tracking pixels' inside a PDF?
- Some PDFs reference remote images or callback URLs that fire when the document is opened in a viewer that auto-loads remote content (e.g. an enterprise reader with a built-in browser). They're rarer than email-tracking pixels but they exist — typically as /URI annotations, Web Capture references or auto-action JavaScript that calls home.
- What's the difference between Clean / Low / Medium / High?
- Clean = no URLs, JS, actions, attachments. Low = only benign mailto:/tel: links. Medium = external http(s) URLs, embedded files or remote-document links — review before sharing widely. High = JavaScript, /Launch, /SubmitForm, RichMedia, XFA, or auto-actions that fire JavaScript — treat with extreme caution.
- Why does it flag /OpenAction and /AA?
- /OpenAction runs when the file is opened; /AA (Additional Actions) runs on page events like 'page open' or 'page close'. They're legal in PDFs and used for legit features (e.g. starting at page 5), but combined with JavaScript they're the standard mechanism for auto-running tracking code.
- Is /URI always tracking?
- No. Most /URI entries are normal hyperlinks — for example, the citations in a research paper. The risk badge weighs them as Medium because they expose the reader's IP to third-party domains the moment they're clicked, which can be enough for some tracking workflows. Review the URL list to decide.
- Can it detect tracking inside encrypted or password-protected PDFs?
- Only if the file is encrypted with an empty password (a flag-only encryption). For real password-protected PDFs, unlock with our Unlock PDF tool first, then re-run the tracking check.
- Is anything uploaded?
- No — pdf.js, the raw byte scan and the risk classifier all run in your browser. The PDF never leaves your device, and discovered URLs are never fetched.
- Can it strip the tracking from my PDF?
- Not yet — this tool reports only. To remove tracking, open the PDF in a desktop editor (Acrobat, Foxit, PDF-XChange) and delete the offending JavaScript / actions / attachments, or rebuild the PDF from the source document with a 'print to PDF' driver that doesn't preserve them.
- How is this different from PDF Inspector and PDF/A Checker?
- PDF Inspector shows structural metadata (pages, version, fonts, bookmarks). PDF/A Checker tests archival compliance against ISO 19005. PDF Tracking Checker focuses purely on privacy: what would phone home or expose your IP if a viewer auto-followed every link.