A small attack surface, described honestly
The strongest security property of PocketPDF is also the simplest: your documents are not on a server. This page explains what that does and does not protect, how the encryption works, and how to report a problem.
Last reviewed: 23 October 2026
1. The security model
PocketPDF is a static bundle of HTML, CSS, JavaScript and WebAssembly. There is no application server, no login database, no document store, no queue and no API that accepts a file. The host delivers files; the browser does everything else. That removes the most common breach scenario for an online file tool: a server full of other people—s documents.
What remains is the browser, your device, and the code delivered to it. The site is served over HTTPS, so the page cannot be modified in transit by a passive network observer. The code is same-origin and does not load scripts, fonts or analytics from third parties at runtime.
This is not a claim that the site is —unhackable—. It is a claim that the valuable thing — your document — is not sitting in a database that could be leaked. Security is the absence of a file store, plus ordinary care around the code that is delivered.
2. PDF encryption, precisely
The Protect PDF tool encrypts files locally with the vendored @pdfsmaller/pdf-encrypt library. It offers:
- AES-256 (PDF 2.0, revision 6) by default — the modern option, supported by current readers.
- RC4 128-bit for older readers that cannot handle AES-256. It is weaker and should only be used when compatibility demands it.
- Permission flags for printing, copying and editing. These are requests to the reader, not hard technical controls.
The password is used to derive the encryption key in the page. It is not sent anywhere, not logged, and not stored in localStorage. When the tab closes, the password and the decrypted bytes are gone from the page—s memory. The original file is never modified.
The Unlock PDF tool does the reverse, but only when you supply the correct password. It is a decryption tool, not a cracker. There is no recovery service, no backdoor and no master password.
The honest weak point is the password. A six-character password on an encrypted PDF is not meaningful protection against a motivated attacker with the file. Use a long passphrase, ideally generated and stored in a password manager, and send it to the recipient through a different channel.
3. The lifecycle of a file
| Stage | Where the bytes are | What happens next |
|---|---|---|
| You choose a file | Your disk; the browser exposes a File handle | The page reads the bytes into its own memory |
| Processing | RAM in the tab (and a worker for heavy engines) | The engine produces a new result |
| Download | A temporary Blob URL | Your browser saves a new file to disk |
| Tab closes | The page—s memory is released | Only your original and your downloaded copy remain |
The service worker cache holds the site—s own assets, not your documents. There is no IndexedDB document store, no session upload, and no —recent files— feature that keeps a copy. The recent-tools list stores tool names, not files.
4. Supply chain and third parties
The processing libraries are vendored into the site and served from this domain. That means no runtime request to a CDN, and no third-party company learning which tool you opened. Versions are pinned in the repository; the licences are credited on the about page.
One deliberate exception: the 31 MB ffmpeg WebAssembly core that video and audio tools need is above Cloudflare Pages' 25 MiB per-file limit, so the pages.dev build loads that single file from the project's own GitHub Pages mirror (voidhere.github.io). It is fetched only when a media tool starts, is the same project's static asset, and no user file or message is sent with the request.
No analytics, advertising, tag manager, session recorder, chat widget or social embed is loaded. The only external action is a link you choose to click.
Vendoring reduces one risk and concentrates another: if a library has a vulnerability, it is the site—s responsibility to update it. The libraries are current as of the last review date. There has been no independent security audit of this site; saying otherwise would be a lie. The code is small enough to inspect, and the network test on the how it works page lets you verify the important claim yourself.
5. Threat model
| Threat | What the architecture does |
|---|---|
| A stranger intercepts traffic | HTTPS protects page delivery. Your file is never in that traffic to begin with. |
| The host is breached | There is no document store to breach. The host serves static files. |
| A malicious PDF exploits a parser | Processing happens inside the browser sandbox, which limits damage. A browser or engine vulnerability could still affect the tab; keep the browser updated. |
| Someone uses a shared computer after you | The tab—s memory is released when it closes, but downloads remain in the Downloads folder and the browser profile may keep history. Use a private window and delete the download on a shared machine. |
| A browser extension reads the page | Nothing here can stop an extension with page access. Use trusted extensions or disable them for sensitive work. |
| A weak PDF password is guessed | Encryption is only as strong as the password. Use a long passphrase and a different sharing channel. |
6. What this does not stop
- A compromised device. Malware, a keylogger or someone with physical access can see the file before or after the browser does.
- A malicious browser extension. Extensions with page permissions can read what the page reads.
- A recipient who shares the file. Encryption protects the file in transit and at rest; it does not control a person who is allowed to open it. Screenshots and re-sharing are outside its scope.
- Weak passwords. AES-256 with —123456— is still a weak lock.
- Metadata you leave in. Encryption does not automatically remove author, title or revision data. Use Sanitize PDF before encryption if that matters.
- Legal authenticity. A password and a drawn signature are not a qualified electronic signature or a notarial act. See the terms.
7. Reporting a vulnerability
If you believe you have found a security issue in PocketPDF — the site code, the service worker, the way a tool handles input, or a configuration mistake — please report it privately instead of posting it publicly first.
- Form: use the feedback form and choose —Security report—.
- Include: the page or tool, browser and version, steps to reproduce, and the impact you believe it has. A proof of concept is helpful; do not include live credentials or a document you do not have permission to share.
- Response: an acknowledgement is the goal within a few days. If the report is valid, the fix and disclosure timing will be discussed with you. There is no bug bounty — this is a free site run by one person — but credit will be given if you want it.
A machine-readable security.txt is published with the contact details. Please do not run denial-of-service tests, automated scanners that generate significant traffic, or social-engineering attempts against the host or the feedback form.
8. Updates and review
The library versions and this page are reviewed when tools change. The site is a static bundle, so a browser that has cached an old version may keep it until the service worker updates. A hard reload (or clearing site data) forces the latest version. The versioned service-worker cache is replaced on activation.
If you spot a claim on this page that no longer matches the code, that is a security documentation bug and worth reporting. The goal is a page that describes the site as it is, not as it was at launch.