Redacting Scanned PDFs That Have No Text Layer
A scanned PDF has no text layer, so there is nothing for a redaction pattern to match against. The document has to be run through OCR first, and the recognized text is what the detection rules search. The redaction is then applied to the regions OCR identified, which means detection accuracy on a poor scan directly limits redaction reliability.
Why a Scan Cannot Be Redacted Directly
A scanned page is a picture. Insurance forms, older records and faxed documents arrive as image-only PDFs, so a text search across the file returns no matches and no regions get marked.
Redaction identifies content through text search or text extraction, and both need text to read. Without a text layer, the PDF redaction library in the Apryse Server SDK has nothing to mark and the PII stays on the page. See redaction use cases by industry for the regulated workflows where scanned records come up.
The OCR-Detect-Redact Sequence
OCR converts the scan's pixels into recognized text, adds it as a text layer and records where each word sits on the page. A text, regular expression or pattern search then runs over the recognized text and returns match positions. Your code marks those positions as redact annotations, a reviewer checks them, and the apply step removes the content. If the output feeds a model next, see PII removal before AI processing:
Getting Started
The scaffold below uses Python 3 on Linux or Windows. The Python 3 get-started guide has the install steps. Redaction ships in the base binary and needs the Redaction add-on license. OCR is a separate module download and needs its own add-on license. Run the code with a free trial key.
License keys are confidential. Do not commit them to public repositories. Use environment variables or a secrets manager to inject your key at runtime.
OCR or ICR: Printed Text Versus Handwriting
OCR reads printed, machine-generated characters. ICR reads handwriting using neural networks that adapt to individual writing styles, and it covers medical forms, insurance claims and historical documents.
A form with printed labels and handwritten entries needs both: OCR for the labels, ICR for the entries. ICR does not read printed text. ICR is a separate add-on, so a handwriting backlog puts a third module on your license.
Both engines produce searchable output that the same pattern search reads. The OCR and ICR pages cover recognition in depth.
Detection Accuracy on Low-Quality Scans
Detection runs against what recognition returned, not against what is on the page. A misread character breaks a pattern, and the SDK cannot recover text the engine never read.
OCR covers Chinese, Japanese, Korean and Arabic-script languages among more than 80. Orientation has limits: text orientation detection is not supported for Arabic-script languages or Korean, so rotate those scans upright before OCR, because a rotated page weakens recognition and detection with it. Mixed-language scans have limits too. Korean can be mixed only with English, and languages from different script groups cannot be mixed, except with English.
That makes the input the first lever. Where you control the scanner, feed OCR greyscale images near 300 DPI, as the document resolution guide describes. The second lever is the pattern. Write patterns against the misreads you see in a sample of your worst pages, such as digits read as letters. Test on that sample before you run the backlog and count the matches you expected but did not get.
Human Review Where Detection is Uncertain
Redact annotations stay visible and editable until Redactor.Redact() runs, so review fits between marking and applying. Each word in ICR output carries a confidence value from 0.0 to 1.0, so your code can route low-scoring handwritten words to a reviewer. OCR output carries no confidence value, so for printed text your code decides which pages go to a reviewer: pages where an expected field matched nothing, pages with little recognized text, or every page in a regulated release.
The reviewer needs the page image, not only the marks, because a miss has no annotation. Your app owns the review queue and the sign-off. Redaction is permanent and irreversible once applied, so review comes first. For the full review workflow, see the compliance redaction process.
Redacting the Image, Not Just the Text
On a scan, true redaction removes the content from the page image itself, not from a layer on top of it. The apply step destroys text, image and vector content inside each marked region. It does not hide that content with clipping or image masks.
Because the page is an image, destroying the image content inside the region is what removes the visible information.
Licensing: Two Add-Ons, One License Key
Redaction and OCR are both Server SDK add-ons, and both packages must be on your production license key. Trial keys include every package. Redaction ships in the base binary. OCR is a separate module download. Handwriting needs the Handwriting ICR add-on as well.
For the difference between the two removal capabilities, see redaction versus sanitization. Redaction removes visible content and is an add-on. Sanitization removes hidden content such as metadata, XMP and embedded scripts, sits in the base package and is Server SDK only.
The Apryse Server SDK runs on your own infrastructure, so scans stay in your environment.
Frequently Asked Questions
Run the scan through OCR first so there is recognized text to search, apply the detection rules to that text, mark the matched regions, then apply the redaction. OCR and Redaction are both Server SDK add-ons, and both packages must be on your license key. Add the Handwriting ICR add-on if the scans carry handwritten entries.
Because detection runs against what OCR recognized, not against what is on the page. If recognition is incomplete or wrong, the pattern has nothing correct to match. Improve the input scan, write patterns against the misreads you see in your sample pages, and add a human review step for pages where an expected match did not appear.
OCR recognizes printed, machine-generated characters. ICR recognizes handwritten text using neural networks and is required for medical forms, insurance claims and historical documents. A scanned form with handwritten entries needs ICR for those fields, and ICR is a separate add-on.
Yes. The apply step destroys text, image and vector content inside the marked region. On a scan the page is an image, so removing the image content inside the region is what eliminates the visible information.
Yes, by looping the same sequence over the document set. The Server SDK provides no work queue or job scheduler, so your code owns the loop, the parallelism and the handling of pages that fail recognition. For the batch pattern, see redacting documents in bulk.
