In-Browser Document Redaction for ID Cards, Bank Statements and Medical Reports

The problem: personal documents shared in full, every day

Renting a flat, applying for a job, opening an account, claiming insurance, applying for a visa: in Pakistan and much of South Asia, each of these involves sending a photo of your CNIC, a bank statement or a medical report over WhatsApp or email. The person asking usually needs one or two details. They receive everything: the full ID number, the account number, every transaction, home address, family details.

These copies end up in phone galleries, group chats and shared drives, and some are later misused for fraud, SIM registration or loan applications in someone else's name. People would redact more if it were easy. Today it is not.

What already exists and the gap

• Desktop PDF editors such as Adobe Acrobat include a redaction tool. It is manual, and not something most people have on their phone.
• Free online redaction sites require uploading the very document you are trying to protect to an unknown server.
• Microsoft Presidio is an open source framework for detecting and anonymising personal data in text and images, designed to run on servers, with recognisers mostly built for Western identifiers.
• Drawing a black box in a photo editor often leaves the original text in a PDF's text layer, where anyone can copy it out.

The gap is a phone-friendly tool that runs completely on the device, understands local identifiers and languages, works on scans and photos, and removes data for real.

Inspiration

WebLLM (Ruan et al., "WebLLM: A High-Performance In-Browser LLM Inference Engine", arXiv 2024) showed that WebGPU and WebAssembly can run language models inside the browser at a large share of native speed. Your project applies the same idea to a narrower, more practical task: running OCR and small entity recognition models in the browser so private documents never need a server. Presidio's design (recognisers, confidence scores, an anonymiser step) is a good model for your detection pipeline.

What you build

• A person sharing a document opens the web app, picks a PDF or photo, reviews the highlighted personal details, adjusts them and exports a clean file.
• Small offices such as estate agents, clinics and HR teams use it to clean documents before storing them.
• Developers reuse the detectors as a small open source library.

The technically interesting part

• On-device OCR on cheap phones. Scans and photos need OCR. Running it in the browser on a low-end phone is slow, so measure, choose model sizes carefully and process pages in a web worker.
• Local identifiers. CNIC numbers have a fixed 13-digit pattern, often written with dashes, and Pakistani IBANs have a known structure and checksum. Rules with validation are more reliable than a model here, and you should measure both.
• Names and addresses. These need a model. Start with an English named entity model in the browser, then build a small labelled set for Urdu and Roman Urdu names and test how far rules and dictionaries get you.
• True redaction. In a PDF, remove the text objects and image regions under each redaction, rewrite the page content, and strip metadata, annotations and embedded files. Then prove it, by running text extraction and OCR on the exported file.
• Offline and private by design. Cache models with a service worker, block all network requests after load, and show the user that nothing is being sent.

How to evaluate it

• Detection quality: precision and recall per data type on a synthetic set of 200 documents with known personal data, including photos taken in poor light.
• Leakage: share of exported files where any redacted value can be recovered by extraction or OCR. The target is zero.
• Performance: time per page on a low-end Android phone and on a laptop.
• Usability: five to ten people redact a document of their own choosing; record time, mistakes and what they found confusing.

Suggested plan

• Weeks 1 to 4: study PDF structure, Presidio and in-browser model runtimes; build the synthetic document set.
• Weeks 5 to 10: PDF text extraction, rule-based detectors and true redaction for digital PDFs.
• Weeks 11 to 16: OCR for scans and photos, named entity model, review screen.
• Weeks 17 to 21: offline mode, leakage tests and performance tuning.
• Weeks 22 to 26: user testing, write-up and demo.

Path to a product

Banks, telecom companies, estate agents and HR teams all handle personal documents, and data protection rules are tightening in many countries. A free consumer app with a paid version for offices (batch processing, custom field rules) is a realistic model. The leak-test suite alone is a useful open source contribution, and the project is a strong portfolio piece for privacy, frontend and applied AI roles.

Scope warning

Do not train large models; use small existing ones and tune them. Do not promise perfect detection, because the user's review step is part of the design. Never add a server-side fallback for convenience, since that breaks the main promise. Start with digital PDFs before scans and photos.

Learn what you need on Sefism

• AI engineering roadmap: running and evaluating small models.
• Frontend development roadmap: web workers, service workers and offline apps.
• Hugging Face Transformers Documentation: choosing and converting a small entity model.
• Speech and Language Processing: named entity recognition basics.
• MDN Web Docs: WebAssembly, workers and the File APIs.
• Cybersecurity roadmap: thinking like someone trying to recover the redacted data.

Get help with this idea

The risk is slow OCR on real phones, or redaction that looks right but leaks. Tauseef can help you choose models, plan the leakage tests and decide which document types to support first. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session