Why OCR Should Run in Your Browser, Not on a Server

Think about the last few things you needed to extract text from. A screenshot of a private conversation. A photo of a contract. An invoice. A form with your address on it. Now think about what “free online OCR” traditionally means: upload that file to a stranger’s server and trust them with it.

The quiet problem with upload-based tools

Most OCR websites work the same way: you upload the image, their server runs recognition, and you get text back. Even when the operator is honest, this model has structural problems:

• Your file exists on hardware you don’t control, at least briefly — and “we delete files after processing” is a promise, not a property you can verify.
• Transit and logs. Files pass through load balancers, temp storage and request logs. Each is a place data can stick around.
• Terms you didn’t read. Some free services reserve the right to use uploads to “improve the service” — that can mean your document becomes training data.
• Breaches happen even to well-run services. A server that never receives your file can’t leak it.

None of this requires malice. It’s just what the architecture makes possible.

The alternative: don’t send the file anywhere

Modern browsers can run real neural networks. WebAssembly is fast enough, and OCR models small enough to download once are accurate enough for printed text. That flips the model: instead of sending your file to the code, the code comes to you.

Here’s what happens when you use the image to text tool on this site:

1. Your browser downloads the OCR models (about 30 MB) and the WebAssembly runtime from this domain, like any other static asset. They’re cached after the first visit. A Korean-specific recognizer (~13 MB) loads only if the first pass looks like Hangul.
2. Recognition runs on your machine. The file never leaves the tab.
3. The result appears on your screen. No request contains your image, your text, or your file name.

The same pipeline handles screenshots and scanned PDF pages. Digital PDFs are parsed by pdf.js in the tab — still no upload.

Verify it — don’t trust it

The nice thing about local processing is that the claim is checkable:

• Open your browser’s developer tools, switch to the Network tab, and extract something. You’ll see model downloads (first run only) and nothing else.
• Or go harder: load the page, turn off your Wi-Fi, and extract. It works, because there’s nothing left to talk to.

Try asking an upload-based service to pass that test.

The trade-offs, honestly

Local OCR isn’t magic; it shifts costs around:

• First load is heavier. You download the engine once (afterwards it’s cached). Upload-based tools have a lighter first page but send your data instead.
• Your device does the work. On a modern laptop this is usually under a second per screenshot; a scanned PDF page takes a few seconds. Very old hardware is slower.
• Language coverage is finite. The default model reads printed English, German, French, Japanese and Korean, plus Chinese. Handwriting and scripts outside that set still favor a big server model.

For screenshots, documents and photos of printed text — the usual case — the local model is accurate enough and instant after the first load. And it’s the only architecture where “your files never leave your device” is a fact rather than a policy.