How Private Browser-Based OCR Works

1. The browser receives temporary file access

When you choose a file, the browser gives the page access to that file for the active session. The website does not receive a permanent operating-system path. PDF Guard reads the bytes into browser memory and checks the type and size. Choosing a document is not itself an upload; an upload would require code to send those bytes in a network request.

2. A PDF page becomes pixels

OCR models work with images. A PDF renderer interprets the page and paints it to a temporary canvas. Digital text may already be extractable, in which case PDF Guard keeps that text and skips OCR for the page. Image-only pages are rendered at a scale intended to balance character detail with memory use.

3. The model recognises text locally

The browser starts a worker so recognition does not freeze the page. It loads the OCR runtime, WebAssembly core and English trained data as static assets. The worker estimates lines and characters and returns text to the application. The canvas and model run on the device; the page image is not sent with the model request because there is no remote recognition request.

4. Local analysis uses the result

Recognised text can be searched for expected checklist items, uppercase abbreviations and labelled details. These checks are explainable patterns rather than a remote generative prompt. The report stays in memory and can be downloaded as a local JSON file. Analytics receives only safe event categories and never the text, filename, checklist wording or detected values.

5. A person verifies important fields

OCR output can be wrong. The person reviewing the document should compare important names, dates, identifiers and instructions with the page image. Browser-based processing changes where recognition runs; it does not remove the need for quality control. If the scan is too poor, obtain a better source rather than assuming repeated OCR will become authoritative.