BASALT · JOURNAL
What happens to your document when you upload it to an online PDF tool
You have a deposition transcript with a witness address in it. You search for a way to black it out, land on a website that says "redact PDF free, no install," drag the file in, and thirty seconds later download a clean copy. The redaction may well be correct. The question worth asking is a different one: what happened to the original in those thirty seconds.
This post is a technical account of that path, not an accusation against any service. Several of these tools are competently built and honest about their handling. The point is that competence and honesty do not change the structural facts, and for privileged or regulated material the structural facts are what govern.
The actual sequence of events
When you drop a file into a browser upload control, one of two things happens. Either the file is processed by JavaScript in your own tab, or it is sent over the network to a server. Almost every tool that performs real redaction, OCR, or compression does the second, because the work requires a full PDF engine and, for scanned documents, an OCR model that is impractical to ship to a browser.
The upload is an HTTP request, normally over TLS. Your file becomes the request body and travels to the service's ingress. It is written to disk or to object storage, because a worker process needs to read it, and workers are usually separate from the web tier. A job identifier is created. A worker picks up the job, opens the file, does the transformation, and writes an output object. You get a download link, often a signed URL valid for some window.
At that point at least three copies of your document exist outside your machine: the uploaded original, whatever intermediate artifacts the worker produced, and the output. Logs may contain the file name, the page count, the byte size, and the client IP. If the tool does OCR, a text extraction of your document exists as a separate artifact, which is to say a plain text copy of everything the scan said.
What "we delete your files" actually means
Reputable services publish a retention window. One hour, two hours, twenty four hours. That statement is almost always true and it is also narrower than it sounds.
Deletion in object storage is a delete marker or an unlink. The bytes are not overwritten. They are reclaimed when the storage layer gets around to it. Versioned buckets keep prior versions until a lifecycle rule expires them, which is a different clock from the one in the privacy policy. Backups and snapshots taken during the retention window persist on the backup schedule, not the file schedule. A nightly database and volume snapshot with a thirty day retention means a file "deleted after one hour" can exist in a snapshot for a month.
None of that is malfeasance. It is how durable infrastructure is built. But "deleted" in a marketing sentence and "unrecoverable" in a forensic sense are not the same claim, and you should not treat them as the same claim when the document is a client's.
The people and systems with reach
Modern web services are assembled from other services. A typical PDF tool involves a cloud provider, an object storage bucket, a CDN, an error tracking service, a logging pipeline, an analytics vendor, and possibly a third party OCR or conversion API. Each is a subprocessor. Each one that touches the request path can, in principle, see the payload or its metadata.
The realistic exposures are mundane rather than dramatic. An engineer debugging a failed conversion pulls the offending file into a local environment to reproduce it. An error tracker captures a request body on a 500 response. A support agent needs to reproduce your complaint and asks you to re-send the file, then keeps it in a ticket. A malformed PDF triggers a crash report that includes a memory fragment.
Then there is legal process. A service holding your document can be served with a subpoena or a preservation order directed at it, not at you. Depending on the jurisdiction and the timing, you may not be notified, and you may not have standing to object before production. For material covered by attorney client privilege, transmission to a third party is precisely the category of act that privilege analysis turns on. Most terms of service also grant the operator a license to process and store content, which is necessary for the service to function and is nonetheless a grant you made on behalf of a client who did not make it.
Cross border and regulatory shape
Under GDPR, sending personal data to a processor requires a lawful basis, a data processing agreement, and, if the processor operates outside the originating region, a transfer mechanism. A free web tool with a click through terms page is not a data processing agreement, and the compute region is frequently unspecified.
Under HIPAA, a vendor that creates, receives, maintains, or transmits protected health information on your behalf is a business associate and needs an executed business associate agreement before you send the first file. Most consumer PDF sites do not offer one and do not claim to. Uploading a chart to redact it is a disclosure regardless of how quickly the file is deleted afterward. The specific obligations are covered in HIPAA and PDF redaction and GDPR and PDF redaction.
Discovery material under a protective order usually carries an explicit clause about where the material may be stored and who may access it. Uploading it to a third party server is often a breach of that order on its own terms, independent of whether anything bad happened to the file.
What is fair to say about these services
Several things in their favor. TLS in transit is genuine protection against interception. Reputable operators do run short retention windows and do honor them. Their redaction engines are frequently better than a desktop annotation tool, because they were written by people who understand that a black rectangle is not a redaction. If your document is a public filing, a marketing PDF, or your own resume, a web tool is a reasonable choice and the risk discussion is academic.
The honest summary is narrower than "cloud bad." It is this: once the bytes leave your machine, the set of parties who could come into possession of that document is no longer a set you control or can enumerate. You have substituted a technical guarantee for a contractual promise from a company whose subprocessor list can change without your involvement. For most files that trade is fine. For privileged, regulated, or protected material it is a trade you cannot make on someone else's behalf.
Judging a tool without taking its word
If you must use a hosted service, the questions that separate serious operators from the rest are specific. Where is the compute region and can you pin it. Is retention enforced by a storage lifecycle rule or by an application cron job. Are backups and snapshots in scope for deletion. Is there a subprocessor list and a change notification policy. Will they sign a DPA or a BAA. Do error tracking and logging capture request bodies.
For a local application the equivalent question is simpler and more testable. Can it reach the network at all. On macOS you can check this rather than trust it, because the sandbox entitlements are part of the code signature and can be read from the binary. An app that has no outgoing network entitlement is prevented by the operating system from opening a socket, which is a stronger statement than a privacy policy.
Whichever path you take, verify the redaction itself independently. Neither a web service nor a desktop app should be believed about its own output. The procedure is in how to check whether a PDF was really redacted, and the parts that survive a careless clean up are listed in what a PDF still carries.
Frequently asked questions
Is it safe to redact a PDF online?
For ordinary documents it is usually fine, and for privileged or regulated material it is not, because the file is transmitted to a third party and processed on their servers. Reputable services encrypt in transit and delete on a published schedule, but the copy still existed outside your control, was visible to their subprocessors, and was reachable by legal process directed at them.
What actually happens to my file after I upload it?
It is sent over the network to the service's servers, written to disk or object storage, read by a worker process that performs the transformation, and stored again as an output file. Logs typically record the file name, size, page count, and your IP address. If the tool runs OCR, a plain text copy of your document also exists as a separate artifact.
Do online PDF tools really delete my files?
Most reputable ones do delete within their stated window, but deletion means an unlink or a delete marker, not overwriting the bytes. Versioned storage keeps prior copies until a lifecycle rule expires them, and backups or volume snapshots taken during the retention window persist on the backup schedule instead. A file deleted after one hour can survive in a snapshot for weeks.
Can an online PDF tool be subpoenaed for my document?
Yes. A service holding your file can be served with a subpoena or preservation order directed at it rather than at you, and depending on jurisdiction and timing you may not be notified before production. This is the main reason privileged material should not be uploaded, since transmission to a third party is exactly the act that privilege analysis examines.
Does encryption in transit make cloud redaction safe for client files?
No. TLS protects the file from interception while it is moving, but it is decrypted at the server so the service can process it. The exposure that matters for client material is not an eavesdropper on the wire, it is the copy sitting in the vendor's storage, logs, error tracker, and backups after the transfer succeeds.
Is uploading a PDF to a web tool a HIPAA or GDPR problem?
It can be. Under HIPAA a vendor that receives protected health information on your behalf is a business associate and needs an executed agreement before you send the first file. Under GDPR you need a lawful basis, a data processing agreement, and a valid transfer mechanism if the compute region is outside your own. Most free PDF sites offer none of these.
How can I tell whether a desktop app is sending my documents anywhere?
On macOS you can read the app's sandbox entitlements directly from its code signature, because network access has to be declared there and is enforced by the operating system. Run codesign -d --entitlements :- against the binary and look for an outgoing network entitlement. An app without one cannot open a socket regardless of what its code tries to do.
Are offline PDF tools automatically more trustworthy?
Not automatically, but they remove one whole category of risk, since the document never leaves your machine. You still have to verify the redaction itself, because a local app can cover text with a rectangle just as easily as a web app can. Check the saved file with an independent parser rather than trusting the interface that wrote it.
Doing it in Basalt
Basalt removes the question by removing the transmission. The redaction engine runs as a separate process with no network entitlement, enforced by macOS at the code signature level, so it cannot send a document anywhere even if it were asked to. There is no account, no telemetry, and no cloud component.
You can confirm that yourself rather than take it on faith: run codesign -d --entitlements :- /Applications/Basalt.app/Contents/XPCServices/BasaltEngine.xpc and read the list. Before any file is saved, a built in verifier re-opens the written bytes with an independent parser and proves the redaction, and if it cannot prove it, nothing is written. It is $29 once for up to three Macs, free for 24 hours, and a 17 MB download.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.