Security: why nothing is uploaded
Every tool in this product runs in your browser. No document, image, signature or result is written to any server, cache or log we control.
Where each tool runs
All 26 tools, covering merging, splitting, editing, signing, compressing, encrypting, converting, OCR and page layout, run entirely on your device using JavaScript and WebAssembly loaded into your browser. Your document's bytes are read from disk into memory on your machine and are never placed in a network request.
There is no upload step anywhere in the product, because there is nothing on our side to upload to. This site is a set of static files. It has no application server, no database and no document storage.
What does leave your device
Loading a web page always makes requests. Here is every one this product can make, and why. None of them carries your document.
| Request | Goes to | Why |
|---|---|---|
| The site itself | This domain | The page, its scripts, styles and icons. Downloaded once and then cached by your browser. |
| Two typefaces | fonts.googleapis.com and fonts.gstatic.com | Albert Sans and Literata, which the interface is set in, plus the handwriting faces offered when you type a signature. Google receives your IP address and browser version as part of serving these files, as any web host does. Loading the page involves no document data. Running OCR in a language written in a non-Latin script also requests a font for that script, by family name only. One exception is the editor: when you export with a Google font selected, the request for that font also lists the distinct characters used in the text you added or edited, so that only the glyphs you need are downloaded. That is a set of characters with repeats removed, not your text and not your file, but it is derived from your document. |
| OCR language data | cdn.jsdelivr.net | Only when you run OCR, and only the first time for a given language. The recognition engine itself is served from this domain, not from a CDN. The language file is a few megabytes (about 3 MB for English, under 2 MB for most others) and your browser caches it afterwards. |
| A page you asked for | The address you typed | Only in HTML to PDF when you give a web address, or when you add a file by URL instead of from disk. Your browser fetches that address directly, so the site at the other end sees the request in the normal way. |
The last two are the only ones you can trigger with a file or an address, and both are things you ask for explicitly. Everything else happens once, when the page loads.
Local storage this product uses
These IndexedDB databases live only in your browser profile. Nothing in them is ever transmitted.
| Database | Store | What it holds |
|---|---|---|
pdf-editor-recovery | sessions | The document you have open in the Editor or Fill & Sign (only when under 5 MB) and your edit state, so a crash or a closed tab can be recovered. |
pdf-editor-handoff | handoff | A short-lived record used only to pass a result from one tool page to the next, such as "Continue with", without a page reload. Deleted the moment it is read. |
pdf-editor | images | Images and signatures you have used in the editor, so they can be reused without adding them again. |
recent-files | recentFiles | The last 50 files you worked with: name, size, source and which tool you used. A reusable copy is kept only for files under 5 MB. |
A little more is kept in localStorage: the options you last used on a tool, under keys like options.merge-pdf, and a single flag recording that you have seen the help button. No file content is ever written there.
You can clear all of it whenever you like, from Saved assets and Recent files, or by clearing this site's data in your browser settings.
Verify it yourself
This takes about a minute and does not require trusting anything on this page.
- Open this site in Chrome, Firefox, Safari or Edge.
- Open developer tools, with F12 or Cmd+Option+I on a Mac, and switch to the Network tab.
- Clear the log, then run any tool, such as Merge or Compress, on a real file.
- Inspect every request that fires. You will see this page's own scripts, styles and fonts, and, only if you ran OCR, the language file. No request will contain your document's bytes.
- For stronger proof, load the page, then turn off your network, then run the tool. It keeps working, because the processing never needed a network in the first place.
That last step is the one worth doing. A site that uploads your file cannot pass it, and no amount of writing on a page like this one can fake it.
The browser features this relies on
None of this is unusual or bespoke. Reading and writing a file without a server is something the web platform has supported for years, and the specifications are public. If you would rather read the standards than take our word for it:
- The File API — how a page reads the bytes of a file you choose, in memory, without transmitting it.
- The File System Access API — how a saved result is written back to the folder you pick.
- WebAssembly — the runtime that makes compression, OCR and rendering fast enough to do on your own device.
- The Chrome DevTools Network panel — the tool used in the steps above, documented by the people who build it.
What this does not protect you from
Running locally removes one risk. It does not remove all of them, and it would be dishonest to imply otherwise.
- Browser extensions run inside the page with you. An extension with permission to read page content can read what you are working on. This is true of every site, including this one.
- A shared or managed computer is still shared. Recovery copies and recent files sit in that browser profile until they are cleared, so use a private window on a machine that is not yours.
- Removing a PDF password with Unlock requires you to know the password. Encryption applied with Protect is real AES encryption, but permission flags that restrict printing or copying are advisory. Many PDF readers ignore them.
- Flatten and redaction-style edits change what a viewer draws. Check your output before sending it somewhere sensitive, the same way you would check anything else.
Reporting a problem
If you find a security issue, please write to support@example.com with enough detail to reproduce it, and give us a reasonable chance to fix it before publishing. Reports about this site's own behaviour are welcome even if you are not sure they matter.