OCR Without Upload: Why Scan-to-Text Should Run Locally
OCR turns a scan into searchable text — but with cloud OCR, that scan is a document you have just sent to someone else's server.
Optical Character Recognition (OCR) is how a scanned contract, policy or application form becomes searchable, copyable text. It is the backbone of document indexing in insurance, legal and public-sector workflows. But the traditional way to run it is to upload the scan to a cloud OCR service — which means sending some of the most sensitive documents an organisation holds to a third party.
That does not have to be the case. Modern WebAssembly OCR engines run entirely in the browser, on the user's device. This article explains the trade-off and why local OCR is the right default for regulated industries.
Why OCR usually means an upload
OCR is computationally expensive: it involves layout analysis, character segmentation and language models. Historically, that pushed OCR into the cloud, where servers could do the heavy lifting. The cost is architectural:
- The scan is uploaded to a third-party OCR API.
- The provider extracts the text.
- The text (and often the image) is stored and returned.
For an ID card, a claim form or a medical record, that is a real data-transfer and processing decision under the GDPR.
How local OCR works
WebAssembly lets a full OCR engine run in the browser. Tesseract.js, for example, compiles the Tesseract engine to WASM and ships the language models alongside it. The result:
- The document image is read into browser memory.
- OCR runs locally, using the device's CPU.
- The extracted text stays on the device.
Nothing is transmitted, stored or inspected. This is the approach behind the FormatFlash OCR tool.
Where local OCR matters most
| Industry | Use case | Why local matters |
|---|---|---|
| Insurance | Policy and claim capture | Personal and medical data |
| Legal | Document indexing | Attorney-client confidentiality |
| Public sector | Application forms | Citizen data, legal restrictions |
| Healthcare | Referral letters | Special-category data |
The compliance argument
When OCR runs locally, the sensitive document never becomes data you hold — which means no legal basis for the document content, no processor agreement for the OCR step, and no retention schedule for the scans. The obligations that remain are the ones for your hosting, analytics and logs, not for the document itself. See our GDPR guide to client-side conversion for the full picture.
A practical starting point
The transition to local OCR does not require a rewrite of your document pipeline. Start with the highest-risk documents — identity scans, medical letters, legal filings — and route them through a browser-based OCR step while the rest of the flow stays unchanged. Because the extraction happens on the user's device, the riskiest files never enter your systems in image form, which is precisely where the compliance value sits. From there, you can expand local OCR to more document types as confidence grows. The result is a document-indexing workflow that is faster for users, lighter for your infrastructure, and far easier to defend to a DPO or an auditor. Over time it also removes an entire class of cloud OCR costs, since the compute is borne by the end user's device rather than your infrastructure. It is a small change with an outsized effect.
Frequently asked questions
What is OCR?
Optical Character Recognition (OCR) extracts searchable text from scanned images and PDFs.
Why does OCR usually require an upload?
Many OCR engines are server-based because they need heavy compute. Cloud OCR means sending the document image to a third party.
Can OCR run in the browser?
Yes. WebAssembly engines such as Tesseract.js run OCR locally, so scans are converted to text without leaving the device.