You can extract text from an image without uploading it by using OCR that runs on your own device. Open Image to Text, drop the screenshot, photo, or scan, and a small neural model loads into your browser and reads the image locally — the file never leaves your computer, and the network panel stays at 0 bytes uploaded. Accuracy is excellent on clear printed text and much weaker on handwriting or blurred photos; the details are below.
Why the upload step matters for OCR specifically
The images people run through OCR are rarely holiday snaps. They are payslips, invoices, bank letters, ID cards, medical results, exam papers, contracts photographed on a desk. A conventional OCR site takes that image, sends it to a server, runs recognition there and returns text. Even with a good deletion policy, you have handed a legible copy of a sensitive document to a third party and have no way to verify what happened to it.
Running OCR locally removes the question entirely. There is nothing to delete because nothing was sent. That is a structural guarantee rather than a promise in a privacy policy — you can check it by disconnecting from the network and watching the tool still work.
How on-device OCR actually works
The browser downloads a small optical character recognition model once and caches it. When you drop an image, the page decodes it, normalises it (greyscale, contrast, deskew), finds the regions that look like lines of text, and runs each line through the model, which maps pixel patterns to characters. The model runs on WebAssembly, and on a machine with WebGPU it can use the GPU instead. All of that happens inside the tab's memory.
The first run is the slow one because the model has to arrive. After that it is cached and recognition on a typical screenshot takes a couple of seconds. Nothing about the process needs a round trip to a server.
What OCR gets right — and what it doesn't
OCR is not magic, and any tool that implies otherwise is selling you something. Set your expectations by the input:
- Screenshots and digital text: near-perfect. Sharp, high-contrast, uniform rendering is the ideal case — error rates are typically a fraction of a percent.
- Flatbed scans of printed pages: very reliable, provided the page is straight and the scan is around 300 DPI.
- Phone photos of printed documents: usually good, but shadows, glare, curved pages and low light cost you accuracy. Retaking the photo well beats any post-processing.
- Small text, faxes, dense tables and multi-column layouts: expect the characters to be right but the reading order to need fixing. OCR reconstructs text, not layout.
- Handwriting: unreliable. Standard OCR models are trained on printed glyphs; cursive and casual handwriting produce output you cannot trust without reading every word.
- Blurry, rotated, or heavily compressed images: poor. Garbage in, garbage out — no engine, local or cloud, fixes missing pixel detail.
The honest rule: if you can read the text comfortably at 100% zoom, OCR probably can too. If you have to squint, so does the model.
Getting the best result from a photo
- Fill the frame with the page and shoot straight on, not at an angle.
- Use diffuse light. Overhead glare on glossy paper wipes out whole lines.
- Prefer a scan or a native screenshot over a photo whenever one exists.
- Crop to the block of text you actually want before running OCR — less noise, fewer false lines.
- If the source is a scanned PDF rather than an image, run it through PDF to Text first; if the page turns out to be an image with no text layer, export the page with PDF to JPG and OCR it.
What to do with the text once you have it
Extracted text is a starting point, not a finished document. Read it once against the original — numbers, names and currency symbols are where OCR errors hide, and a misread digit in an invoice is worse than no text at all. From there you can paste it into a document, or push it straight into another local tool: turn it into a shareable file with Text to PDF, or have it read aloud with Text to Speech, which also runs a neural model on your device.
How to tell an OCR tool is really local
Three checks, in order of how hard they are to fake. First, turn off your network connection: a genuinely local tool still recognises text, a cloud one fails. Second, watch for an upload progress step — local tools begin work the instant the file is read. Third, open your browser's network tab, or use the live privacy panel on every File Transmute page, and confirm the byte count stays at zero while you convert. A tool that passes all three cannot be sending your payslip anywhere.
The trade-off is real but small: the model is a download on first use, and very heavy batches will be slower than a server farm. For everything short of industrial-scale document processing, on-device OCR is the correct default — and the one where you never have to wonder where your scan ended up.