How we test

A PDF tool that says it removed something can be wrong in a way you cannot see. The page looks clean, but the thing is still in the file. So for every tool that promises something is gone, HerePDF is checked on the saved file, not on what the page looks like.

Why the page is not enough

Drawing a black box over a name is the usual way to “redact”. It changes how the page looks and nothing else: the text is still in the file, selectable and searchable underneath. The same gap shows up elsewhere. A deleted page can stay in the file, and a cleared Author field can survive in an old copy of the document's metadata. The redaction guide explains the mechanics.

The check

The tests read the output as a determined person would. They take the raw bytes of the saved file, unpack every compressed stream, decode every hex-encoded string (including UTF-16 text, which is how form values are stored), and search all of it for the thing that should be gone. Nothing in that step trusts the library that wrote the file, so an object that is no longer reachable from any page, but was still written out, is found anyway.

A second check reads the same file back with PDF.js, an independent PDF reader, to confirm that what a viewer shows and can extract matches what the tool claimed.

A worked example

We made a one-page PDF with two lines of text, one reading “Account number 4471-9920-3318”, and removed that line two ways. Results from 5 October 2026:

The black rectangle looks identical on screen and leaves the number fully recoverable. HerePDF's Redact tool draws the black box into the page image, rebuilds the page from that picture and removes the old page from the file, so the scan finds nothing. The cost is visible in the size: the whole redacted page is now a picture, so the other line on that page is no longer selectable text either. That is the price of the content being gone and not merely covered. You can try the same thing with the Redact tool.

What this has caught

The method exists because it found real problems in our own tools, all since fixed:

• Redact rebuilt each marked page but left the original page's text in the downloaded file (found and fixed 25 September 2026).
• The Metadata tool was documented as unable to remove XMP metadata. The earlier test had only checked that the link to it was gone, not that the bytes were.
• A PDF built from phone photos carried each photo's hidden GPS location straight into the file.

The same whole-file scan now guards Redact, Metadata, Remove Hidden Data, Flatten, Fill Form, Page Layout, Extract Images, Password Protect and the tools that drop pages (Merge, Split and Organize). Browser tests also drive the built site in Chromium and check the file each tool actually downloads, including Redact.

What this does not claim

• These are automated checks. We do not claim every release is hand-tested on every browser and device.
• A test proves the file we built contains no trace of what we looked for. It cannot promise the same for every PDF in the world, so each tool page states its own limits.
• Some tools hide rather than delete, and say so: cropping and cutting a page in half narrow what is visible and leave the page content in the file, and a poster layout does the same. Redact is the tool that removes.
• Remove Hidden Data and Metadata are not a full sanitiser. Content drawn on the page, text hidden by colour and anything inside a picture are untouched.

Check it yourself

You do not have to take our word for any of this. Take a file you have redacted, with any tool, and unpack it with a command-line tool such as qpdf --qdf --object-streams=disable in.pdf out.pdf. Then search out.pdf for a phrase that should be gone. A plain text search can miss text stored with unusual font encodings, which is why our own scan also decodes hex strings, but a phrase that turns up is proof it is still there.

Found something we missed? Please tell us, with the tool and the kind of file. That is the most useful report we can get.