About 2,800. That's roughly how many times a week anyone downloads Presidio's image redactor — the best-known open-source tool for pulling personal data out of a picture — according to Snyk's package index. Not a month. A week. Set that against the number of scanned contracts, ID photocopies and signed consent forms sitting in folders right now, and you don't have a technology gap. You have a market that quietly decided who its customer was, and it wasn't the person holding the document.
The Extraction Assumption
Open the documentation for any well-regarded PII tool and look at the first function call. It takes a string. You hand it text; it hands back positions — characters 40 to 51 are a name. That is a clean, honest interface, and for its intended job it's the right one.
But look at what it assumes. It assumes the text already exists. Somebody, somewhere, already turned the page into characters. Call it the Extraction Assumption: the entire category starts one step after the hardest part of the work, and never says out loud who is supposed to do that step.
For a developer, this is fine, because the developer is that somebody. They have a database column, a chat log, a JSON field. Text is where their problem already lives. For the person with a scanned PDF, the assumption is the whole problem — and it has been silently assigned to them.
The tell is in the install instructions
Presidio, the de-facto standard here — built at Microsoft, now community-governed — does ship an image redactor, and it is good work. Read how you get it running: install the Python package, then go install Tesseract OCR separately for your operating system, and use a recent version — the docs note testing against v5.2.0. The medical-imaging variant carries a further caveat, that it redacts the pixels but does not scrub personal data that may still be sitting in the file's metadata.
Every one of those sentences is useful to an engineer. Every one of them is unreadable to an HR manager with forty scanned employment contracts. That is not a documentation failure. It is a statement of who the product is for, and it is an honest one.
The big cloud vendors do the same thing with more revenue attached: they will sell you text extraction as one service and entity detection as another, and leave the wiring between them to you. Two products, one integration project, and a bill. The composition work — the part where the errors actually happen — is the customer's problem by design.
The incumbent's answer is "do the hard part yourself"
Adobe Acrobat is where most people actually try this, and its answer is a two-step: run Recognize Text on the scan first, then use Search & Redact. Which is to say, perform the extraction yourself, then we will take it from there. Same assumption, just with a human standing in the seam.
That seam is where the support threads live. The recognition quietly fails on a low-contrast fax. The search finds eleven of the fourteen names because the twelfth was read with a broken ligature. Nothing throws an error at any point. You are asked to be the quality gate on a process you were never shown.
We made the same assumption. Ours was worse.
I would like to write this as an outsider's critique. I can't, because we shipped the Extraction Assumption too, in three separate places, and only found them by going and measuring.
Our pipeline had to decide whether a page was worth reading as an image, and it asked the wrong question — "is there a big image here?" — using area as a proxy for importance. A company name in a letterhead strip is about half a percent of a letter page. It fell straight through. Size was never the question. The question is whether any text is drawn over the image: text over it means a watermark or a background, and no text over it means the extractor is blind to it, at any size.
Worse: the function that checked whether a page contained embedded images at all called a method our PDF library didn't have. The error was swallowed at debug level. It had been returning "no images here" for as long as that dependency had been pinned — including on a page that was 65% image. A silent false is indistinguishable from a correct answer, which is exactly how it survived.
And when a user drew a redaction box by hand over a scanned letterhead, our editor read the page's text layer, found nothing inside the rectangle, and captured nothing. The user marked the one thing they most wanted gone, and we silently did not remove it. On a scanned page we had just read — and then thrown the words away.
Three bugs, one root cause, and it is the same root cause as the market's: we reached for the text and treated the picture as someone else's step.
Who pays for the silent miss
A tool that crashes is annoying. A tool that reports "no personal data found" on a page full of names is something else, because it doesn't fail — it issues a clean bill of health, and transfers the liability to a person with no way to audit it.
Think about who is actually holding scanned documents. Not the platform team at a large bank; they have engineers, and they have the text already. It's the two-lawyer practice, the clinic scanning intake forms, the caseworker with a photocopied ID, the HR coordinator with signed offer letters. Disproportionately, the picture-shaped documents are the sensitive ones — and disproportionately, the people holding them cannot write the integration that the entire tooling market assumes they will.
They are also the least able to absorb what happens when it goes wrong. The engineer who mis-wires a redaction pipeline files a bug. The person whose ID photocopy went out unredacted files a police report.
What building for the other customer actually changes
It changes the input. The unit of work is the page as it exists, picture and all — not a string somebody else was supposed to produce.
Concretely: text recognition isn't a step the user runs first, it's inside the pipeline. A box drawn by hand that catches no words goes and reads its own page again, so a manual correction can't silently do nothing. Detected names become rectangles painted over pixels, with a fresh searchable layer rebuilt underneath so the file stays usable. If you want the mechanics rather than the argument, we wrote them up in how to redact scanned PDFs and images.
None of this is more clever than what Presidio's authors built. It is the same components, arranged for someone who was never going to open a terminal. And it runs on the machine the document is already on, which for a photocopied passport is not a preference.
Common questions
Why do redaction tools miss text inside images?
Because most of them never look at the image. Their entry point accepts text, so a scanned page arrives with nothing to search and returns nothing found — silently. The picture has to be treated as the input, not as a step the user performs first.
Isn't this what Presidio's image redactor is for?
It is, and it works. It is also a Python package that expects you to install a text-recognition engine yourself, which is a reasonable ask of a developer and an impossible one for most people holding scans. We wrote about where its text engine fits and where it doesn't in why we built our own engine instead of shipping Presidio.
Why does on-device matter more for scanned documents?
Because scans skew sensitive — IDs, medical intake, signed agreements. Uploading them to a service to have their secrets removed means the secrets arrive at the service first, which is the risk you take when the document itself is the sensitive thing.
The bottom line
The reason it is so hard to redact a PDF full of images isn't that the problem is unsolved. Every piece has existed for years. It's that the pieces were built and priced for developers working on text streams, and the assembly — the expensive, error-prone part — was left to whoever happened to be holding the file.
Most of them aren't developers. They're someone at a front desk, making a photocopy of a document a stranger handed over because they needed something — a job, a treatment, a place to live. That person didn't consent to a pipeline. They consented to one office, on one afternoon, being careful with a piece of paper about them. Whatever we build should make being careful the default, and not a thing you have to be technical enough to earn.
promptShield runs text recognition, detection and redaction on scanned PDFs and images on your own device — no package to install, no separate recognition step to run first, and nothing uploaded. Try it on the scan your current tool says is clean.