Detection Coverage & Limitations
Automatic detection is a first pass, not a guarantee. This page sets out plainly what RedactProof finds on its own, what it doesn't, and where a human review step is part of the intended workflow.
Last updated: 21 Jul 2026
What is detected automatically
RedactProof combines pattern matching (with checksum validation where a format has one, such as payment cards, IBANs, and NHS-style identifiers) with an on-device AI model. Coverage spans over 70 categories: names, addresses, emails, phone numbers, dates of birth, government identifiers across the UK, EU, US, Canada, and Australia, financial account details, healthcare identifiers (medical record numbers, accession and specimen IDs, patient IDs, health insurance member numbers), device and equipment serial numbers, employee IDs, vehicle identifiers, IP and MAC addresses, and credentials such as API keys and access tokens.
Every automatic suggestion carries a confidence score and shows which detection layer produced it. Nothing is redacted without your approval: the workflow is detect, review, approve, export. For high-assurance work, treat the review step as mandatory - the certificate records what was redacted and whether each item was auto-detected or manually added.
What needs manual redaction
Some content is not analysed by automatic detection today. If your documents contain any of the following, plan for a manual pass:
- Barcodes and QR codes. Their encoded content is not decoded. A QR code that encodes a patient identifier will not be flagged - draw a redaction box over it.
- Handwritten and electronic signatures. There is no signature detection category. Signature images and signature blocks need manual boxes.
- Faces and photographs. Photographs of people are not detected as identifying content.
- Logos, stamps, and watermarks that identify an organisation or individual.
Manual redaction produces exactly the same pixel-burn result as automatic redaction - the distinction is only in how the content gets found, and the redaction log records which was which.
Scanned pages and OCR
Pages with little or no selectable text - scanned pages and uploaded images - are OCR'd automatically before detection runs, on every plan. Uploaded JPG and PNG files are converted and OCR'd the same way.
The nuance is mixed pages: a page that already has substantial native text plus an embedded image (a scanned wristband or label pasted into an otherwise typed report) is not automatically OCR'd, because the page as a whole doesn't look scanned. RedactProof flags such pages in the editor and prompts you to re-scan them - right-click the page number and choose "Re-scan this page". Until a page is re-scanned, text inside its embedded images is invisible to detection.
Document metadata
Pixel-burn export builds an entirely new PDF containing only rasterised page images (plus an optional OCR text layer generated by RedactProof). Nothing from the source file's internal structure survives: no document properties, XMP metadata, annotations or comments, embedded files or attachments, thumbnails, revision history, or digital signatures. The only metadata in the output is what RedactProof writes fresh at export time:
- Title - blank
- Producer - "RedactProof (redactproof.com)"
- Subject - "Redacted document", or a certificate reference on certified exports
- Keywords - "redacted", or on certified exports a machine-readable copy of the verification certificate (certificate ID, document hashes, signature, redaction counts - never document content)
- Modification date - the export time
- Author and Creator - your attribution identity: your custom username or reference ID if you've set one, otherwise your account identifier. Blank for anonymous exports. This is deliberate - it attributes the redaction work - but it does mean the exporter's identity is readable in the file's properties.
You can confirm this on any exported file with our free Inspect tool (which also runs entirely on-device) or a third-party metadata inspector. What's included in an export is documented on the exports page.
Consistency over time
Detection models are versioned. For a given model version, the on-device engine is deterministic: the same document produces the same results. Models do improve over time, though, and versions are not pinned per account - a document processed today and re-processed after a model update may be detected differently (usually better). Certificates record which detection engines produced a document's redactions, so an audit trail survives model updates.
The practical guidance: treat each document as reviewed at time of processing, rather than relying on bit-identical reproducibility across releases.
Found a gap?
If detection misses something in your documents that you'd expect it to catch, we want to know - real documents drive coverage priorities. See the FAQ for how to get in touch, and never include unredacted sensitive content in a report.
How your files are processed
Files load into the editor and, out of the box, all processing runs on your device - no cloud uploads, no data residency concerns. Like a desktop app, without the install.
Only cryptographic fingerprints reach our servers, used to verify redactions. The files themselves - contents, filename, everything - stay on your device.
An optional upgrade you choose to enable. It sends only extracted text for analysis, never your original files - processed in memory, not stored.