What happens when you upload a PDF to an online tool

Uploading means handing over a copy

When you upload a PDF, its bytes travel from your device to a computer run by someone else. From that moment there are at least two copies: yours, and theirs. Everything that matters for your privacy is about the second copy: who can read it, what is done with it, and when it stops existing.

The connection itself is usually encrypted (the padlock in the address bar means HTTPS), which stops other people on the network from reading the file on its way. It does not limit what the service can do once the file arrives: at the other end it is decrypted and the service has it in full.

The usual path of an upload

Services differ, but an upload generally goes through the same stages:

1. Transfer. Your browser sends the file, usually as a form upload.
2. Reception. The server holds the incoming bytes in memory or writes them to a disk as they arrive.
3. Checks. A careful service checks the size and what the file really is, judged by its content rather than its name, and refuses anything it should not keep.
4. Processing. A program on the server opens the PDF to merge, compress, convert or read it.
5. Storage of the result. The output is saved so that you can download it, usually behind a link.
6. Deletion. At some point the original and the result are deleted, or they are not. This is the stage you can see least of, and the one a privacy policy should describe most precisely.

Along the way, other parties can be involved: the company that hosts the server, a content delivery network in front of it, and any service the operator uses for logs, analytics or advertising.

Questions to ask before you upload

• Does the file need to leave my device at all? Many PDF jobs (merging, splitting, rotating, compressing, filling forms, signing) can be done inside a modern browser.
• How long is it kept, and is deletion automatic? Look for a number, and for what happens to the result as well as the original.
• Who can download it? Is the download link long and random, can it expire, can you revoke it, can it carry a password?
• Is it used for anything else? Analytics, training, “improving the service”.
• Who else handles it? The hosting provider, the location of the servers, any subprocessors.
• Can I check what is sent? Any website can be checked with the browser's developer tools; the last section shows how.

A worked example: FileBench

FileBench answers the first question differently from a typical upload-based tool, so it makes a useful example of both paths.

Most of the time, the PDF is not uploaded

At the time of writing, 34 of FileBench's tools accept a PDF. All of them do their PDF work inside your browser: reading pages with pdf.js and writing new files with pdf-lib, both running in the page. The PDF itself is not sent to FileBench's server by any of them. Five of them (Edit PDF, Sign PDF, Redact PDF, Combine files into one PDF and OCR PDF) can send something else: a picture you add that your browser cannot open, such as most TIFF files, which goes to the server only to be turned into a PNG and sent straight back. An iPhone HEIC photo is not sent, because the server cannot read it either. Each tool page says so before you start. The companion guide, How FileBench processes your files in the browser, explains the work itself.

You can confirm this for any tool: the network panel shows no request anywhere near the size of your file.

When a PDF does reach the server: sharing a result

There is one way a PDF reaches FileBench's server: you choose to create a share link for a result, so someone else can download it. Here is that path, stage by stage, as the code does it. The server is hosted by Render in its Singapore region and is reached through Cloudflare, which Render places in front of the services it hosts; both see the request on its way, as any web host does.

1. Transfer. Your browser sends the result files to /api/upload as a form upload. Requests that come from another website are refused, and each network address can make a limited number of uploads per minute.
2. Reception. The server writes each file to disk as it arrives rather than collecting it in memory. A file is discarded as soon as it passes 50 MB, a request may carry at most 25 files, all stored files together may not exceed 1 GB, and one network address may store at most 500 MB in 24 hours. (These are the values configured for helixmedia.biz at the time of writing.)
3. Checks. Each file is identified by its content, not its name. A file is kept only if it is one of the types FileBench's tools produce: PDF, common image formats, Word, Excel and PowerPoint files, ZIP, and plain text, CSV, Markdown or JSON. Programs, scripts, web pages, SVG images and anything unrecognised are refused, whatever they are called. The file name is cleaned of folder parts and characters that could disguise its type.
4. Processing. None. A shared file is stored exactly as your browser produced it.
5. Storage of the result. The file is stored with an expiry time 60 minutes after the upload, and with a SHA-256 fingerprint of its content. Creating the link (/api/share) produces a random token of 22 characters. You can add a password, which is stored only as a salted hash, never as the password itself, and a limit on how many times the link may be opened. A link can ask for up to 30 days, but it can never outlive the stored file behind it, so on helixmedia.biz it ends when the file does: 60 minutes after the upload at most.
6. Downloading. The person you send the link to receives a separate download address for each file, signed with a secret key so it cannot be forged or altered, valid for 10 minutes and usable a few times at most. Every download is checked against the link: once it has been revoked, has expired or has reached its limit, it no longer works, including download addresses handed out earlier. A PDF is always delivered as a download rather than opened as a page on helixmedia.biz, under a security policy that stops a stored file from running anything in the browser.
7. Deletion. The server sweeps out expired files every 5 minutes, and again shortly after each upload, and removes them from disk, not just from a list. Pressing Revoke stops the link at once. FileBench currently runs on a free hosting plan whose disk does not survive a restart, so a restart, which can happen at any time, deletes every stored file and ends every link early. That is a limitation as well as a privacy property: do not rely on a share link to keep a file.

What the server records about the run

Separately from your files, the page sends a small record of each run to /api/jobs: the tool, whether it ran in your browser, whether it finished, the total size of the input and the result in bytes, and the number of files. A failure adds a short description with file names and paths replaced by the word “file”. The record carries a keyed hash of your network address, your browser's User-Agent and its language setting rather than the address itself. It holds no file and no file name. At most the latest 5,000 such records are kept, and on the current hosting they are erased whenever the server restarts. The privacy page lists every field, and how long each kind of record is kept.

Check any tool yourself

1. Open the tool's page, then open your browser's developer tools (F12, or Cmd+Option+I on a Mac) and choose the Network tab.
2. Clear the list, add your PDF and run the tool.
3. Sort by size, or look at the largest requests. An upload of your PDF shows up as a request whose size is about the size of the file.
4. Click it and look at its Payload (or Request) tab to see what was sent, and at the response to see what came back.

On FileBench, what you will see instead is the page's own code, /api/health, the small /api/jobs and /api/events requests described above, and on helixmedia.biz requests to Umami (cookieless analytics) and to Google's advertising servers when a page loads Google AdSense (the privacy page names the domains). For an OCR tool, the first run in a language also downloads that language's model from tessdata.projectnaptha.com. None of these carries your file, its name or its contents; a file is sent only to /api/decode, /api/encode, /api/office or /api/upload, in the cases the tool page lists.

If a tool works without a request the size of your PDF, your PDF stayed on your device. If there is one, the tool's privacy policy is where to find out what happens next, and the questions above are the ones to hold it to.