You’re about to run a signed contract, a scanned ID, or a set of medical records through some online PDF tool, and right above the upload button there’s a reassuring line: “Files are automatically deleted after 1 hour.” It’s meant to answer the privacy question before you ask it. And in a narrow sense, it does — a lot of these tools genuinely do delete what you send them, on schedule, as stated. But it’s worth being precise about what that sentence is actually promising, because “we delete it later” and “we never had it” are not the same guarantee, even when the deletion promise is made in complete good faith and kept exactly as written.

What a deletion promise actually requires you to trust

Read that sentence again slowly: “we delete your file after an hour.” Every word in it is doing work, and every word is a place where something has to go right.

For a server to process your PDF at all, your file has to leave your device, travel across the network, arrive at someone else’s infrastructure, and sit on a disk (or in memory) long enough to be opened, decrypted if it was encrypted, and operated on. That’s not a criticism of how these tools are built — for a tool that runs its heavy lifting on a server, there’s no other way to do it. But it means that for the full duration of that hour (or however long “processing” takes), your file exists somewhere outside your control, readable by whatever process is handling it, and subject to whatever else happens to touch that infrastructure in the meantime.

The deletion promise, when kept, cleans up after that window. It does not undo it. And “when kept” is carrying more weight than it looks like it is, because a deletion policy is a promise about future behavior, not a description of what already happened. Making good on it depends on several separate things all going right:

  • The deletion code has to be correct. A cleanup job that’s supposed to run hourly can fail silently, skip a directory, or have an off-by-one bug that leaves files behind — this is an ordinary category of software bug, not a hypothetical one.
  • The deletion has to reach every copy. A file that was ever written to disk for processing is a natural candidate for infrastructure that exists precisely to prevent it from disappearing — automated backups, replicated storage, a CDN cache, log aggregation that happened to capture a request body during debugging. A “delete the file” job that only targets the original path doesn’t necessarily reach any of those.
  • Nothing has to go wrong before the hour is up. A breach, a misconfigured storage bucket, or unauthorized access to the server in that window exposes exactly the file you were trying to protect, deletion policy or not — the policy only describes what happens if nothing goes wrong first.
  • The file was decrypted server-side to be processed at all, unless the tool is doing something genuinely exotic like homomorphic encryption — which, in practice, no consumer-facing PDF tool does, because it’s slow and impractical for this kind of work. So for that whole window, the plain, readable contents of your file exist on someone else’s machine, not an encrypted blob that’s meaningless without a key you hold.

None of this means the deletion promise is a lie. Most tools that make it are staffed by people who mean it and have a cron job or lifecycle rule that does what it says. The point is narrower: even a deletion policy followed perfectly still means your file was, for some real span of time, sent somewhere, stored somewhere, and decrypted somewhere you don’t control. The policy shortens the exposure window. It doesn’t close it.

Why “never uploaded” is a structurally different claim

Compare that to a tool where the processing happens entirely inside your own browser — using WebAssembly builds of PDF libraries and JavaScript running locally, rather than a server on the other end of an upload.

This isn’t a stricter privacy policy. It’s a different architecture, and the distinction matters because a policy is a promise about behavior, while an architecture is a fact about what’s structurally possible. There’s no server in the request path for your file’s bytes, which means there’s no backup system that could have copied it, no log that could have captured it, no breach window during which it sat somewhere decrypted, and no cleanup job whose correctness you have to take on faith — because none of those things ever had anything to act on. You can’t misconfigure a backup of a file that was never sent anywhere to be backed up. “Nothing to delete because nothing was sent” isn’t a slogan; it’s a literal description of what did and didn’t cross the network.

That’s the actual shape of the difference: a deletion policy is a promise layered on top of an architecture that received your file. “Never uploaded” removes the need for the promise by removing the architecture the promise was covering for.

It also sidesteps questions a deletion policy never even gets asked. Depending on a service’s terms of use, a file sitting on its servers can potentially be looked at by a support engineer debugging a ticket, or fall under language broad enough to let the company use it to improve its own product — deleting the file an hour later doesn’t undo whatever happened to it in that hour. A file that was never sent anywhere can’t be looked at by a support engineer or folded into someone else’s product, for the same reason it can’t be backed up or breached: there’s nothing sitting on their servers to do any of that to.

How to verify this yourself — don’t take our word for it either

Here’s the thing about that last paragraph: you shouldn’t have to trust it just because it’s written on a website, including this one. This is one of the few privacy claims on the internet you can actually check yourself, in about thirty seconds, with a tool that’s already built into your browser.

  1. Open any PDF tool’s page (this site’s tools included).
  2. Open your browser’s developer tools — right-click anywhere on the page and choose Inspect, or press F12 (Cmd+Option+I on a Mac).
  3. Click the Network tab. This shows every request the page makes over the network in real time.
  4. Now actually use the tool: pick a PDF file and run whatever operation the page offers — merge, split, compress, redact, whatever it is.
  5. Watch the Network tab while it runs.

If the tool is truly client-side, you’ll see the page load its own assets (JS, WASM files, fonts) when it first opens, and then, when you actually process your file, essentially nothing new goes out — no request carrying your file’s bytes, no multi-megabyte upload showing progress. If a tool does upload your file, you’ll see it plainly: a POST request with your filename, a payload size matching your file, and a progress bar that’s really tracking an upload, not a made-up loading animation. There’s no ambiguity once you’re looking at the actual network traffic — this is a claim you can independently confirm, not one you have to take on faith from either a competitor’s privacy policy or this paragraph.

On any of this site’s tools, that check comes back the same way every time: your file’s bytes never appear in the Network tab, because the merging, splitting, compressing, redacting, or OCR is being done by pdf-lib, qpdf compiled to WebAssembly, pdfjs-dist, or tesseract.js running as code inside the tab you already have open — the same way a spreadsheet formula runs on your machine, not someone else’s.

The one gap “never uploaded” doesn’t close by itself: cosmetic redaction

Everything above is about whether your file’s bytes left your device. But if you’re using a tool specifically to black out a name, an account number, or a signature before you share a file — which is exactly what Hide Text is for — there’s a second, unrelated question worth asking, and “never uploaded” doesn’t automatically answer it: did the redaction actually remove that text, or did it just draw a black box on top of it?

That’s not a hypothetical edge case. A well-known category of redaction failure looks, at a glance, exactly like a properly redacted document — a solid black rectangle sitting over the sensitive part of the page — while the original text is still there underneath it, as a real, selectable text object. Copy that part of the page and paste it into a text editor, or open the PDF’s raw content stream in any text viewer, and the “redacted” text comes right back out. The box covered it visually. It didn’t remove it.

The fix for that has nothing to do with uploads and everything to do with what the redaction step actually does to the page. Hide Text handles it by rendering each page you’ve marked with a black rectangle out to a flat image — pixels, not a text layer with a rectangle drawn over it — and rebuilding the output file page by page from that image and whichever pages you left untouched, rather than editing the original document in place. The text characters under the black box don’t survive that, because that page isn’t text anymore by the time it’s saved. As a side effect of building the output as a fresh document instead of an edited copy of the original, metadata fields like Author or Title that might have been sitting on the source PDF don’t carry over into it either.

That comes at a real cost, and it’s worth being upfront about it rather than pretending it’s free: a redacted page turns into an image, so it’s larger than the original page, and its text — including the parts you never blacked out — is no longer selectable or searchable in the result. That’s the tradeoff for a redaction that actually destroys the text underneath instead of one that only hides it from view.

When this genuinely doesn’t matter

It would be dishonest to write a post about privacy architecture without saying plainly: not every PDF needs this. A flyer for a garage sale, a public meeting agenda, a template you downloaded and are converting to a different format — none of that is sensitive, and there’s no meaningful risk in running it through a tool that happens to process files on a server. The privacy of “never uploaded” matters in proportion to what’s actually in the file: a signed contract, a scanned passport or driver’s license, medical records, financial statements, anything with someone else’s personal information on it, or a document under an NDA. Matching the tool to what you’re actually protecting is the right instinct — not reflexively treating every PDF as a secret.

It’s also worth being honest that client-side processing isn’t a strictly better architecture for every job, full stop — it’s better specifically for the goal of not exposing file contents to a third party, and that’s a real but narrow win. There are real tradeoffs that come with keeping everything in the browser:

  • Browser memory is finite in a way a server’s isn’t. A very large PDF — hundreds of megabytes, thousands of pages — can push against the memory a browser tab is willing to give a page, in a way that a beefy server process wouldn’t blink at. Client-side tools generally handle typical documents (tens or low hundreds of pages) comfortably, but there’s a ceiling that server-side processing doesn’t have in the same way.
  • Some workloads are just computationally heavy. OCR on a long scanned document, for instance, is genuinely CPU-intensive work, whether it runs via tesseract.js in your browser or an equivalent server-side engine — running it locally means your own device’s CPU does the work instead of a data-center machine’s, which can mean it takes longer on modest hardware.
  • It’s not the right lens for collaboration or storage. A tool that never uploads your file also has nowhere to keep a copy for you, share a link to it with someone else, or sync it across your devices — if what you actually need is a shared, always-available copy of a document, that’s a fundamentally different job than “process this file without exposing it,” and no privacy architecture on either side of this changes that.

None of that makes “we delete it later” the better privacy choice — it doesn’t change the fact that the file still transited a network and sat on a server that had to decrypt it to work on it. It just means “never uploaded” is solving one specific problem very well, not every problem a PDF tool might need to solve.

The actual question to ask

The next time a tool tells you it deletes your file after an hour, the useful follow-up question isn’t “do I believe them” — it’s “did my file need to leave my device in the first place for this to work?” For most everyday PDF operations — merging, splitting, rotating, compressing, adding a password, redacting a name or account number before you share a file, converting scanned pages to searchable text — the honest answer is no, and a tool that runs entirely in your browser, like Hide Text for blacking out sensitive content or Password Protect a PDF for locking one down, gets you the result without ever putting that question to a deletion policy at all.