What to tell your IT or security team about browser-based PDF redaction
Someone else now has to approve the tool you wanted to use. That is a different problem from redacting well — it is an evidence problem. Here is what you can actually show, what a reviewer will find on their own, and where this kind of tool honestly falls short.
Almost every guide about redaction is written for the person holding the document. This one is written for a moment that happens after that: you have found a tool that does the job, and now somebody in IT, security, compliance or legal has to decide whether you are allowed to use it. They are not asking how to draw a black box. They are asking a different question — what happens to a sensitive file when it meets an unfamiliar website — and they will decide on evidence, not on enthusiasm.
The mistake most people make here is to reply with the marketing line. “It’s client-side, nothing gets uploaded” is true of a browser redaction tool, and it is also exactly what a reviewer hears from every vendor who has never earned the claim. Assurance is not evidence. What moves a review along is a small number of things the reviewer can check themselves, plus an honest account of the parts that genuinely do not meet an enterprise standard. This page gives you both.
The four questions a reviewer is actually asking
Security review questionnaires differ, and any real one at your organisation takes precedence over anything here. But underneath the paperwork, browser-based document tools tend to be assessed on the same four axes. Answering these four directly, in this order, tends to shorten the conversation considerably.
1. Where does the document go? This is the only question that really matters, and it is the one you can answer most convincingly, because it is directly observable. A tool that processes a PDF in the page reads the bytes from your own disk into the tab and never needs to transmit them. You do not have to assert that; you can show it, and the next section explains how.
2. What code runs, and where did it come from? This one people answer badly. A browser tool is still software arriving over a network, and a reviewer is entitled to know whose software. On this site the answer is: one script served from this domain that does the redaction itself, plus two well-known general-purpose libraries — a PDF rendering engine and a library that assembles the output file — loaded at specific pinned versions from public code hosts. That is an ordinary software supply chain, no more exotic than installing a desktop application, and it is fetched before you have chosen a file. Say it plainly rather than letting them discover it.
3. What is retained, and where? The redaction script on this site uses no browser storage of any kind — no cookies, no local or session storage, no database in the browser — and there is no account, no sign-in and no session to retain anything against. What is retained is what you yourself save: the original wherever it already lived, and the exported file in your Downloads folder. On a machine you do not exclusively control, that local residue is the genuine exposure, which is why we treat it as its own topic.
4. What can you prove afterwards? Here you should concede rather than argue. Because no service is holding your document, no service is producing an audit log about it. If your process needs to show that a particular person redacted a particular document on a particular date, that record has to be yours — a redaction log, a file-naming convention, a note in the matter file. This is the single most common reason a browser tool is refused, and it is usually solvable by adding your own record-keeping rather than by changing tools.
The demonstration that ends the argument
Reviewers believe network captures. Offer to run this in front of them, or to record it, and attach it to the request.
Open the page and the Network tab
Load the tool with developer tools open on the Network panel. Let the page settle, then clear the request list so only what follows is captured.
Do the whole job with the capture running
Choose a harmless PDF, draw boxes, and download the redacted file using the tool on this page. Watch the list while you work.
Read the list out loud
Point at each entry and name it: page assets, the two libraries, the rendering engine’s background worker, analytics. None of them carries your document, and all of them are requests for code, not for content.
Then cut the cord
Load the page while connected, open one PDF so every piece of code has been fetched, disconnect the machine from the network entirely, and redact the real document offline. A transfer that is physically impossible needs no trust at all.
That last step is the strongest evidence available to you, and it costs nothing. It works because the browser caches the code it already fetched; there is one ordering trap in it — the rendering engine’s background worker is not downloaded until the first time you actually open a PDF — which our guide to redacting a PDF with no internet connection walks through in detail, including what each failure looks like when you get the order wrong.
Where a tool like this will legitimately fail a review
If you only present strengths, a competent reviewer will assume you have not looked. Raise these yourself.
No contract, no agreement, no service level. A free public tool is not a procured vendor. If your policy requires a data processing agreement for anything touching regulated data, a website with no commercial relationship cannot supply one — even when it never receives the data.
Third-party code without integrity pinning. The library script tags on this site specify exact versions but do not carry subresource integrity hashes, so the browser is not checking the delivered file against a known digest. That is a real, checkable finding. Its practical impact is bounded by the fact that the redaction script itself makes no network requests at all, but a reviewer is right to note it.
Ordinary web page scripts. Like most public sites, these pages carry analytics and advertising code. It is unrelated to the redaction machinery and it never sees your document, but it is visible in any capture and it is not something a locked-down environment may permit.
A permissive response policy. The pages are served with only a minimal content security policy rather than a strict script allowlist. If your standard requires strict CSP on anything handling sensitive material, that standard is not met.
No central control. There is no single sign-on, no managed configuration, no way for an administrator to enforce settings or to prevent someone saving the original to the wrong folder. Everything depends on the person at the keyboard, which is fine for one document and weak as an organisational control.
Weighed honestly, that list says something specific: this is a good answer for an individual handling their own document, and a poor answer for a standardised high-volume regulated pipeline. Saying that yourself will earn you more credibility than any of the strengths above.
Common mistakes and misconceptions
Leading with “it’s private” instead of “here is how to check.” Privacy claims are the cheapest thing on the internet. Verifiability is the expensive thing, and it is the thing you happen to have.
Treating “no server involvement” as answering every question. It answers question one completely and questions two through four not at all. Reviewers who feel a question was dodged escalate.
Escalating to a person instead of narrowing the request. “Approve this website” is a large ask. “I need to black out two fields on one PDF before it goes to the court, on my own machine, and here is the capture” is a small one, and small ones get approved.
Solving the wait by moving the document. Emailing the unredacted file to a personal address so you can use a tool at home converts a paperwork delay into an actual disclosure. If the machine or the network is the obstacle, move the tool, not the file.
Forgetting the machine itself. Approval of the tool says nothing about the desk it runs on. On a shared, borrowed or public device the leftovers are the exposure, and that has its own checklist in our guide to redacting a PDF on a public or shared computer.
Assuming a refusal is permanent. Most refusals are about the missing record rather than the tool. Add a redaction log and a naming convention, resubmit, and the same reviewer often says yes.
Related guides
Explore more ways to redact PDFs privately, or use the redaction tool above:
Frequently asked questions
How do I prove to a reviewer that the document is not being sent anywhere?
Do not argue it, demonstrate it. Open the browser’s developer tools on the Network tab, clear the list, then choose a PDF, draw boxes and download the result. Every request that appears is a page asset, a library or an analytics call that happened before you picked a file. The even simpler version is the disconnection test: load the page, open one harmless PDF so every piece of code is fetched, then disconnect the machine from the network entirely and do the real redaction. A transfer that cannot physically happen is more persuasive to a reviewer than any policy page.
What will a security reviewer find that I should mention before they do?
Three things, and raising them yourself is better than being caught by them. First, the page loads two general-purpose libraries from public code hosts rather than from this domain, and those script tags carry no subresource integrity hashes, so the browser is not cryptographically verifying the delivered file against a known digest. Second, the site serves analytics and advertising scripts like most public web pages, which is unrelated to the redaction machinery but will show up in a network capture. Third, the response carries only a minimal content security policy, not a restrictive script allowlist. None of these moves your document, but all three are legitimate review findings.
Is a browser tool enough for a regulated or contractual workflow?
Often not, and it is better to say so early. A free public web tool typically has no contract, no processing agreement, no service level, no single sign-on, no centrally enforced configuration and no server-side audit trail, because there is no server holding your document to audit. If your obligation is to show that redaction was performed by an approved process with retained evidence, you can still satisfy it, but the evidence has to come from your own records rather than from the tool. Where the obligation names procured software specifically, use the procured software.
What is the smallest thing I can send to unblock the request?
A short note with four parts: what the document is and why it needs redacting, that the processing happens in the browser on your own machine so the file is not handed to a third-party service, the specific third-party code the page loads and from where, and what you will keep as your own record of the change. Offer the disconnection demonstration as an attachment or a five-minute screen share. Reviewers reject vague assurances far more often than they reject a narrow, specific request they can verify.