Skip to content

field_note · jul 19

Why on-device OCR is the smarter way to extract text: a look at Textquill

Cloud OCR sends every screenshot to someone else's server. On-device OCR runs the model where the pixels already are. Here's why that trade keeps winning, using Textquill as the example.

Most OCR tools work the same way under the hood: you hand over an image, it travels to a server, a model reads it, and the text comes back. That round trip is invisible when it works. It's also the part doing the most damage, because the thing you uploaded was almost never just text.

On-device OCR flips the arrangement. The model runs where the pixels already are, inside the browser or the app, and nothing leaves the machine. That single change fixes a surprising number of problems at once. Textquill is a clean example of the pattern, so I'll use it to make the case concrete.

The hidden cost of cloud OCR

When you screenshot a page to pull two lines of text out of it, you usually capture more than two lines. A support ticket. An invoice with an account number. A Slack thread with a name in it. Send that to a cloud OCR endpoint and you've shipped all of it, not the part you wanted.

That has three costs that rarely show up on the pricing page:

  • Exposure. The image sits in someone else's logs, cache, or training pipeline, governed by a policy you didn't read.
  • Latency. The upload, the queue, and the download are almost always slower than reading the image locally.
  • Fragility. No network, flaky VPN, or a blocked domain means no OCR. A local model just works.

None of these are exotic edge cases. They're the normal conditions of grabbing text off a screen at work.

What "on-device" actually buys you

Running the model locally isn't a privacy gimmick. It changes the physics of the tool.

Nothing to leak

If the image never leaves the device, there's no upload to intercept, no server-side copy to subpoena, no retention window to worry about. The strongest privacy guarantee is the one that's structural rather than promised. "We don't store your images" is a policy; "the image was never sent" is an architecture. (More on that distinction in how Textquill keeps your data truly private.)

Speed you can feel

Local inference skips the entire network path. For the small images OCR usually deals with, a screenshot to selectable text is effectively instant, which matters because the whole point is to not break your flow to go copy something.

It works offline

On a plane, behind a corporate proxy, on a locked-down machine: the model is already there. Nothing to reach.

Where the trade-off actually is

On-device OCR isn't free of cost, and pretending otherwise is the usual marketing tell. The honest trade is this:

  1. Model size. A local model ships with the tool, so it has to be compact. Modern on-device OCR is good enough for screen text, printed documents, and clean UI, which is exactly what browser-based OCR is for.
  2. Your hardware does the work. Inference runs on your CPU or GPU instead of a datacenter's. For screenshot-sized images this is a non-issue on any machine from the last several years.

Notice what's not on that list: accuracy on the workloads that matter. For extracting text from screens, on-device models have closed the gap. You're not sacrificing quality for privacy. You're getting both, and paying with a few megabytes of download.

Textquill as the concrete case

Textquill is a browser extension that does OCR on-device: you point it at a screenshot or an image on a page, and it turns the pixels into editable, copyable text without a server ever seeing the image. It's the pattern above, shipped as a one-click tool instead of an SDK you have to wire up.

Try the on-device path once and the cloud round trip starts to feel absurd. Grab Textquill, screenshot anything with text in it, and watch it become selectable without a single request leaving your browser.

The reason to care isn't brand loyalty. It's that the architecture is simply the better default for the common case: pulling text off a screen, quickly, without turning every screenshot into a data-handling decision. Once a tool proves the local model is good enough, the cloud version has to justify why your image needs to leave at all.

The takeaway

Cloud OCR made sense when local models couldn't read. That constraint is gone. When the model can run on your device, sending the image somewhere else is pure downside: slower, leakier, and dependent on a network you don't control. On-device OCR isn't the privacy-conscious compromise. On the workloads most people actually have, it's just the better tool. Textquill is one of the cleaner demonstrations of that, and a good place to feel the difference for yourself.

Working through something like this? I help teams ship AI and cloud systems that hold up, and cost what they should.