You're about to drag a client contract, a patient chart, or last month's payroll file into a website you found by searching "PDF compressor free," and something makes you pause. That instinct is worth listening to. A PDF is just a container — once it leaves your device, you generally have no way to verify what happens to the bytes inside it, no matter what the landing page promises. This guide covers what actually happens on a typical upload-and-convert site, how to test whether a tool truly processes locally, and where uploading confidential material anywhere but your own machine is a policy problem regardless of privacy claims.
What Actually Happens When You Hit Upload
Clicking upload on a typical online converter sends the raw file, over HTTPS at best, to a server the company controls or rents from AWS, Google Cloud, or similar. From there, a file's journey can include hops you never see:
- Temporary storage — an S3-style bucket or local disk.
- A queue, handed to a worker process on different infrastructure than the one you connected to.
- A third-party API: OCR, conversion, and heavy compression are often outsourced, so your file can touch two or three companies for one website visit.
- Automated scanning — antivirus, and at some providers, proactive scanning for illegal content. Usually a process, not a person, but still something reading your document.
- Logs referencing the filename or metadata, sometimes even after the file body is discarded.
None of this makes a server-side tool bad by default; reputable vendors run these steps in audited, access-controlled environments. The point is that "upload" is the start of a chain, and every link is a place your document could be exposed by an incident you can't see into.
Why "We Delete Files After 1 Hour" Is a Promise, Not a Guarantee
Almost every online PDF tool's privacy page promises deletion "after 1 hour" or similar. Take it as a stated policy, not a verifiable technical property — and it typically doesn't cover every copy. It applies to the primary storage the app writes to, but commonly not to:
- Backups. Disaster-recovery backups run their own retention schedule (30-90 days is common), independent of the app's delete logic.
- Logs. A filename or hash written to a log line inherits that log's own retention, often weeks or months.
- Subprocessor copies. A file sent to a third-party API is governed by that company's retention policy, which you likely never read.
- Caches and CDNs. An intermediate caching layer can hold a copy the front-end company doesn't fully control.
None of this means a tool is lying — "we delete after 1 hour" describes intent, not a cryptographic guarantee. Read the actual privacy policy before trusting it with anything sensitive.
How to Tell Whether a Tool Really Processes Locally
You don't have to take any site's word for it, including this one. Three checks, easiest first:
- Open the network tab. Press F12, open Network, load your file, run the tool. A client-side tool shows only the page's own JS/CSS and maybe a small ad ping — nothing carrying your document. A server-side tool shows a POST or PUT sized like your file, going to the company's API domain.
- Turn off your wifi mid-task. Let the page load fully, disconnect, then process a file. A genuinely local tool keeps working. Caveat: some browser tools fetch a worker script from a CDN at run time, not page load — if uncached, they fail offline even though the document never left. Real example here: PDFCraft installs as a PWA, but the pdf.js worker comes from a CDN rather than fully cached, so page-rendering tools can fail offline. Failing offline proves the tool needs a network for something — not that the something is your document.
- Change the file size, watch the clock. Process a 1 MB file, then a 40 MB one, same connection. Time scaling with upload bandwidth means data is leaving; time tracking page count and CPU instead means it isn't.
Questions Worth Asking Before You Upload Anything
- Where does the file go, specifically? "We take security seriously" isn't an answer; a named location is.
- Is a Business Associate Agreement or Data Processing Agreement available? If your org requires one and the tool can't sign one, that's a hard no.
- Does the policy mention using content to "improve" the service or train models? Some free tools' terms include broad license grants — read the clause, not the summary.
- Who are the named subprocessors? A reputable service lists them, often on a page for compliance customers.
- What's the retention story for backups and logs? Most FAQs skip this — email and ask.
Where Uploading Is Off the Table, Full Stop
In several professional contexts the answer isn't "check carefully" — it's "don't," regardless of a tool's privacy story.
| Context | Why uploading is prohibited |
|---|---|
| Legal (privileged material) | Routing a privileged document through an unrelated server is treated as a waiver risk, regardless of that vendor's actual security. |
| Medical records (U.S., HIPAA) | A covered entity needs a signed Business Associate Agreement before any vendor touches health information; a free tool rarely offers one. |
| HR / employee records | SSNs, health data, and pay records are commonly restricted to approved vendors — an unapproved tool is shadow IT. |
| Finance / banking documents | Bank statements and cardholder data fall under frameworks like PCI-DSS and GLBA that limit which systems may touch them. |
| Government / classified material | Classified and Controlled Unclassified Information generally can't touch a system lacking formal accreditation, which no public web tool has. |
None of this is legal advice — the line depends on your jurisdiction and your organization's policy, so confirm with counsel or compliance rather than treating this table as a ruling. If your employer has already banned a category of document, that stands even after you've verified a tool processes locally.
Where Client-Side Processing Helps — and Where It Doesn't
Running the PDF engine in your browser removes real risk: the document's bytes never traverse a network, so there's no retention question and no subprocessor to vet. For confidential-but-not-regulated material — an internal draft, a one-off contract — that's a meaningful improvement. It doesn't do everything, though:
- It doesn't protect you from a malicious site. "Processes in your browser" describes today's code, not a law of physics — an update could add a network call tomorrow. Run the checks above yourself, rather than taking it on faith.
- It doesn't hide that you visited the page. Analytics and ad scripts operate independently of the PDF engine; local processing keeps the document off a server, not your page views off Google.
- It doesn't protect a compromised device. If malware or someone with physical access already has your machine, the file was exposed before you opened a browser tab.
What This Site Itself Loads, in Plain Terms
In the interest of the same honesty this guide asks of every other tool, here is everything PDFCraft's pages load from outside this domain:
- Google Analytics 4 and Google AdSense — analytics and the ads that keep the tools free.
- Google Fonts — a stylesheet from fonts.googleapis.com plus fonts from fonts.gstatic.com, so Google sees a request every page load.
- Lucide icons, from unpkg.com.
- pdf.js and pdf-lib from cdn.jsdelivr.net, plus JSZip from the same CDN on PDF to Images, zipping your rendered pages.
- A ko-fi.com badge and link for anyone who wants to support the site.
Microsoft Clarity, a session-recording tool, was present until August 2026 and has since been removed. None of the above ever receive the document you're working on or any password typed into a tool like Protect PDF. They see that you visited a page, not what's inside your file. Full details are on the security page.
Locking a file before sending it? See how PDF password protection actually works. Need content actually gone rather than just locked? See how to redact and remove PDF content — a black box isn't deletion.
Heads up: No tool, local or server-side, can retroactively secure a document that already has copies sitting in email inboxes, chat threads, or a downloads folder synced to the cloud. Picking the right PDF tool solves one link in the chain, not the whole chain.
Frequently Asked Questions
Is it illegal to use a free online PDF converter for work documents?
Not automatically — it depends what's in the document and what your employer's rules require. A marketing PDF is fine anywhere; a patient record without a Business Associate Agreement can be a real violation even without a breach, because the problem is the missing authorization.
If a tool says it's GDPR-compliant, is it safe to upload confidential files?
Not necessarily. GDPR compliance covers lawful basis, data-subject rights, and breach notification — not a promise your file won't be retained or handed to subprocessors. Compliant and "never touches a server" are different claims.
How can I check that PDFCraft doesn't secretly upload my file somewhere?
Run the checks above here: DevTools' Network tab before using Merge PDF or Compress PDF, watching for a request sized like your file, then wifi off once the page has loaded. Tools that render with pdf.js, including Compress and PDF to Images, are the exception if the worker isn't cached yet — a caching gap, not an upload.
Are desktop apps like Adobe Acrobat or Apple Preview automatically safer than a browser tool?
Their core local operations process locally the same way a browser tool does. But many now bundle cloud features that do upload the file. The distinction is per-feature, not per-app.
Does using a local tool make my document HIPAA- or PCI-compliant?
No. Those frameworks cover the whole handling process, not just whether a file touched a third party. Local processing removes one risk; it isn't a certification.
If I use the Black Box tool to cover sensitive text, is the file then safe to share?
No. A black box is a cover, not a deletion — the text underneath remains in the file and is extractable by copy-paste or any PDF parser. See how to redact and remove PDF content for what actually removes it.