ZERO-TRUST PDF

Check these claims

Instructions for testing what this site says, rather than believing it.

This site makes a handful of specific claims about what happens to your file, and none of them is the sort you should have to take on faith. What follows is how to check them yourself. It needs about five minutes and nothing beyond the browser you already have open.

Each check below is one you run. Where a check has a limit, the limit is written down next to it, because a proof that quietly stops short is worse than no proof at all.

Work with the network switched off

Open the tool and let the page finish loading. Then take the machine off the network — Wi-Fi off, cable out, airplane mode, whichever is quickest. Now drag in a PDF, mark something, and export it.

What happens, and where the limit is

It works. The document opens, renders, exports and downloads with no connection available at any point. That is only possible if the work is happening on your machine, because there is no other machine it could be happening on.

The limit, stated plainly: it is the loaded page that keeps working, not the whole site. Navigating to another page here needs the network like any ordinary website. If a scanned document renders blank offline, that is a real bug and worth reporting — the image decoders load separately from everything else.

Watch the network yourself

Open developer tools before you add a file. F12 or Ctrl+Shift+I on Windows, Cmd+Option+I on a Mac. Open the Network panel and clear the log, so you are reading a clean slate rather than the page load.

What you will see, including the one request

Now add your document and export it. No request appears carrying the file. You can sort by size: the transfers that happen are small, and nothing approaching the size of your PDF leaves.

You will see one request, and it is worth naming before you find it and wonder. Cloudflare Web Analytics posts to /cdn-cgi/rum on this domain. It reports page timings and a page view. It is injected by the host rather than by anything in this code, it sets no cookies, and it has nothing to do with the file you opened — that page view fires whether or not you ever add a document.

Read the finished file back

The first two checks show the file never left. This one shows the redaction did something.

Using Verify, and what it cannot tell you

After an export, open Verify. It loads the file you just exported back off your disk and pulls out whatever text can still be extracted, then lets you search that text for the thing you meant to remove.

Its limit is the important part, and Verify says so on screen: a page that was rasterized has no text layer at all, so a search finding nothing there is trivially true and proves nothing about that page. Verify reports which pages still carry text and which do not, rather than reporting a clean bill of health. For redaction specifically, extraction is the weaker check. The strong one is that the exported file is rebuilt from scratch, and nothing belonging to a marked page is copied into it.

What none of this proves

These checks tell you what this build does on your machine today. They do not tell you what a build shipped next month does. Code changes, and no check you ran in the past constrains a version you have not run. That is a real limitation and no amount of confidence here removes it.

Browsers, bugs, and your own machine

Which browser you are holding matters too, so here is where the offline check has actually been run: desktop Chromium, desktop Firefox, and Chrome on Android. Safari is not on that list, on macOS or on iOS. Assuming it behaves the same would be exactly the sort of untested claim this page exists to discourage. So if you run the offline check in Safari, you know something about this site that nobody else does — send it to security@redactpdffree.com and the list above gets longer or the page gets corrected.

They also do not prove the engine is free of bugs. It has had at least one that mattered, documented on how to properly redact a PDF, where redacted content survived in the exported file and every text-based check came back clean. The checks here would not have caught it. That is exactly why the failure is written up rather than quietly patched.

And they say nothing about the security of your own machine. A browser extension with permission to read page content can read your document while it is open, whatever this site does.

If a check fails

If you run one of these and it does not come out as described, that is a vulnerability report rather than a complaint. Send it to security@redactpdffree.com and you will get a reply within 48 hours. Reports where the exported file still contained something you had marked are read before anything else.

The rest of the architecture, including what the engine does and what it cannot handle, is on the about page.