What is browser OCR?

Browser OCR is optical character recognition performed by code running in your web browser, rather than by a service running on someone else's machine. The recognition engine is compiled to WebAssembly and downloaded like any other page asset; the document is read from local memory; the extracted text is produced in the tab and never has to leave it.

Conventional OCR works the other way around. You upload the file, a server recognises it, and JSON comes back. That is easier to build and usually more accurate, and it means a copy of your document exists on infrastructure you do not control.

How browser OCR works

A browser OCR pipeline has four stages, and only the third is recognition proper.

• Read — the file is loaded into memory from the file input. No network request carries it.
• Decide — if the input is a PDF that already contains a text layer, the text is read directly and OCR is skipped entirely.
• Recognise — pages without usable text are rasterised and passed to a WebAssembly OCR engine running in a worker thread, so the interface stays responsive.
• Assemble — recognised words carry positions, which are used to rebuild lines, paragraphs, tables and reading order.

The PDF text layer comes first

This is the step most descriptions of OCR skip, and it matters more than the engine. A PDF exported from accounting software already contains the characters, with exact coordinates. Running OCR on it would be slower and less accurate than reading what is already there — you would be converting perfect text into pixels and then guessing at the pixels.

A well-built pipeline therefore inspects each page and picks a route per page, so a printed contract with one scanned signature page is handled correctly rather than being forced down one path.

Browser OCR versus cloud OCR

Neither is universally better. They fail in different places, and the honest comparison is about which failure you can tolerate.

• Accuracy on hard inputs — cloud wins. Server-side models are larger than anything you can reasonably ship to a browser, and handle poor photographs better.
• Privacy of the document — browser wins, decisively. The file bytes never leave the device, so there is no copy to secure, subpoena or breach.
• Speed on a single page — usually cloud, because the server hardware is dedicated and the model is already warm.
• Speed on a private network with no upload bandwidth — browser, because there is nothing to upload.
• Cost at volume — browser, because recognition runs on hardware you are not paying for.
• Predictability — cloud, because you control the machine; browser recognition depends on the visitor's device and available memory.
• Offline capability — browser, once the assets are cached.

Where cloud OCR is the better choice

If you are processing tens of thousands of documents a night, need the highest achievable accuracy on creased phone photographs, or require handwriting recognition, a server-side service is the right tool. Browser OCR is not a universal replacement and claiming otherwise would be dishonest.

Where browser OCR is the better choice

It suits documents people hesitate to upload: invoices with bank details, receipts tied to a personal card, contracts, identity documents, medical letters. It also suits anyone who would rather not take on the obligations that come with holding other people's documents — because the simplest way to protect a file is never to receive it.

What browser OCR does not mean

It does not mean the page makes no network requests. The engine and its language models are downloaded, and an application may still record that a conversion happened. In our case the server receives a short job record — filename, file type, size, page count and a key identifying the attempt — because a conversion allowance cannot be enforced by asking the browser to count honestly.

The precise claim worth making is narrow and checkable: document bytes are processed locally in the browser and are never uploaded, while limited metadata is transmitted for quota and record-keeping. Anything broader than that is marketing.

Accuracy expectations

Recognition quality depends far more on the input than on the engine. A flat, sharp, well-lit scan of printed text reads well in any modern OCR. A creased receipt photographed at an angle in poor light does not, in the browser or on a server. Handwriting is a separate problem that general-purpose OCR does not solve reliably.

The useful safeguard is not a higher accuracy claim but a confidence score attached to every extracted field, so uncertain values are flagged for review instead of being written silently into a spreadsheet.

How EasyInvoiceOCR implements it

Recognition runs client-side with Tesseract.js compiled to WebAssembly. PDFs with a text layer are read directly through PDF.js and OCR is skipped. Five base language models are available — English, French, Arabic, German and Spanish — plus two combined modes, English + Arabic and English + French, for bilingual documents. The engine and language models are served from our own origin rather than a third-party CDN.

Extracted fields carry a confidence score and a review flag, both of which are written into the exported spreadsheet rather than shown once and discarded.