The finance team needs to merge a scanned contract with a signature page. The PA needs to remove a page from a board pack before forwarding it. The recruiter needs to convert a candidate's Word CV into PDF. None of these people are engineers. All of them will, right now, search "merge PDF free online", click the first result, upload the file, and download the output. It takes ninety seconds. It also, in most cases, ships a full copy of that document to a server somewhere and leaves it in a bucket for anywhere from 60 minutes to "forever".
PDFs are the single highest-risk file type for this kind of shadow IT, because unlike a JSON payload a PDF is almost always the finished, human-readable version of something sensitive: a contract, a payslip, a medical letter, a passport scan, a signed NDA. This post is for the people who have to answer for that upload after the fact.
What actually happens to the file
The typical "free online PDF" workflow: your browser POSTs the file to /upload, the server writes it to disk (or S3), a background worker processes it, and the browser polls for a download URL. Most services keep the file for at least an hour so their CDN can serve the download reliably. Many keep it for 24 hours "in case you re-download". Some keep it indefinitely for training or debugging, and only a minority are transparent about which category they fall into.
None of this is visible to the person uploading. From their perspective the tool is instant and clean. From a data-protection perspective, you have just executed an unlogged, un-DPA'd data transfer to a third country (the servers are usually in the US or one of two Eastern European countries), and the file may include a data subject's name, national ID, salary, or health information.
Why this matters more than JSON leakage
A leaked JSON payload is bad, but usually small and hard to attribute to a specific data subject. A leaked PDF is different: it is often a single document containing the full name, address, and financial or medical details of one identifiable person. Under GDPR that is exactly the kind of processing that triggers Article 33 breach notification if the file is later exposed — and "exposed" includes "the vendor's S3 bucket was misconfigured", which happens roughly every six weeks somewhere in the industry.
The reputational side is worse. "We lost a customer's contract because an intern uploaded it to a free site" is a story that survives contact with a journalist. Nobody wants to be quoted saying it.
The tests to run on any PDF tool before allow-listing it
The single most useful test: open the tool's network tab, load a small PDF, and click the primary action. Does the file's bytes appear in an outbound request? If yes, it is a server-side tool and belongs in the same policy bucket as any other data-processor: DPA required, retention documented, sub-processor list published, breach-notification SLA.
If the file bytes never leave, congratulations — the tool is running client-side, using PDF.js, PDF-lib, or a WebAssembly build of MuPDF inside the browser. From a compliance standpoint, no data transfer occurs, so no DPA is required and no cross-border transfer rules apply. This is the category we build Bluebird in.
Secondary tests: is there a Content-Security-Policy header that blocks outbound requests? Does the page load third-party analytics or session-replay tools? (Session-replay is fatal here — it silently records the file preview, defeating the whole "client-side" claim.) Is the tool served over HTTPS with HSTS? Is there a public /security or /.well-known/security.txt page?
What client-side PDF processing can and cannot do
It is worth being honest about the limits. Client-side PDF tools can do everything most business users need: merge, split, reorder, rotate, delete pages, extract images, add text, redact regions, compress, convert to and from common image formats, fill forms, and add basic signatures. Modern browsers give you enough CPU and memory to handle 500-page documents on a laptop without breaking a sweat.
What client-side tools cannot easily do: OCR at scale on hundreds of scanned pages (possible with Tesseract.js but slow), advanced digital signatures requiring hardware tokens (needs a native app), and conversions from esoteric legacy formats that require a full LibreOffice runtime. For those three cases, a server-side tool with a proper DPA is the correct answer. For the other 95% of use cases, a browser-only tool covers you.
How to roll this out without a memo nobody reads
First, publish an internal bookmark page called something obvious like "Approved tools" with three or four browser-only tools categorised by task (PDF, images, JSON, hashing). Put it on the intranet home page. Add a one-line explanation: "These do not upload your files." That's the whole training program for 80% of the population.
Second, for the finance and HR teams specifically — the two highest-risk PDF-uploading populations in most companies — do a 20-minute walkthrough. Show them the network-tab test on a public tool with a fake payslip. Watch the payslip appear in the request body. Nobody who has seen that demo forgets it.
Third, add "uploads to third-party file-processing services" to your DLP monitoring. Even a simple proxy rule that logs uploads over 100 KB to known free-tool domains gives you visibility you didn't have before. Don't block outright; blocking pushes it to phones. Log, review monthly, coach where needed.
The bottom line
The engineers already have this problem solved for themselves — they know which tools are safe. Non-technical staff don't, and they process the more sensitive documents. Giving them a two-bookmark solution to their two-second problem is the highest-leverage, lowest-cost data-protection intervention most companies can make this quarter. It doesn't need budget, doesn't need a vendor RFP, and doesn't need a new headcount. It needs one page and one lunch-and-learn.
