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 limits, stated plainly. The first visit has to happen online, and for a few seconds afterwards the site finishes storing its own files on your device. From then on the pages and tools open with no connection at all, including after a reload. In a browser that does not allow a site to store files that way, such as a private window in some browsers, only the page you already have open keeps working. If a scanned document renders blank offline, that is a real bug and worth reporting: the image decoders are stored 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, and what each request is
Now add your document, mark something and export it. No request appears carrying the file. Sort by size: the transfers that happen are small, and nothing approaching the size of your PDF leaves.
You may see a few requests, and they are worth naming before you find them and wonder. On a first visit the site's own files are fetched from this domain so they can be kept for offline use: scripts, fonts, image decoders and the sample documents. Cloudflare Web Analytics loads its script from static.cloudflareinsights.com and posts to /cdn-cgi/rum on this domain to report page timings and a page view, and Cloudflare may request /cdn-cgi/speculation to fetch a page you are likely to open next. That beacon is injected by the host rather than by anything in this code, it sets no cookies, and it fires whether or not you ever add a document. None of these carries a byte of your file, and the upload size of each one shows it.
Read the finished file back
The first two checks show the file never left. This one shows the redaction did something.
The report, and what it cannot tell you
Every export ends in a report. It takes the exact bytes your browser just saved, opens them again from scratch, and checks them: that each page you marked has no text left in it, that nothing you searched for remains in the pages that kept their text, that no Social Security, card or account number is left there either, and that the file carries no hidden text, metadata, attachments, scripts or earlier versions. You can search the exported text yourself underneath.
Its limit is the important part, and the report says so on screen: a page that was turned into an image has no text at all, so a search finding nothing there is trivially true and proves nothing about what is drawn on it. The report shows those pages instead and asks you to look. For redaction specifically, reading text back is the weaker check. The strong one is structural: 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. The newer half of it, opening a page or reloading with the connection already off, has so far been run in desktop Chromium only. Safari is not on either 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.