OCR without the paywall: free, local image-to-Markdown in your browser
OCR is the feature online converters are most reluctant to give away. Drop a scanned document on the popular tools and you will meet the same pattern: a page limit on the free tier, an upload requirement, and a subscription form between you and the recognized text.
This site takes the opposite approach. The OCR engine runs entirely inside your browser, the document never leaves your machine, and there is no account to create because there is nothing to meter. This article explains how in-browser OCR works, what its honest quality envelope is, and when a desktop tool is still the better answer.
Why OCR ended up behind paywalls
Recognition is computationally expensive in a way that plain format conversion is not. Reading a DOCX and writing Markdown is string manipulation; recognizing a page image means running a trained model over every glyph. On a server, that cost multiplies by every user, every page, every day — so vendors meter it with page caps, daily limits, and Pro tiers.
The upload requirement follows from the same architecture. If the model lives on the vendor's server, your document must travel to it, which is how OCR became the poster child of the upload-and-paywall model: your scanned contract sits in someone's queue, and the meter runs while you wait.
How OCR runs inside a browser tab
The engine here is Tesseract — the same open-source recognizer that powers desktop tools like ocrmypdf — compiled to WebAssembly so it runs at near-native speed in any modern browser. The language data it needs downloads on demand, per language, and is cached locally so repeat visits skip the fetch.
Scanned PDFs take one extra step. A PDF page is not an image yet, so the pipeline renders each page to a bitmap first — at double resolution for sharper glyphs — using the same PDF.js renderer browsers use to display PDFs. The bitmap goes to Tesseract, the recognized text comes back, and the Markdown writer assembles the result. Every stage executes on your machine.
What 'local' buys you
Privacy is the headline. Medical records, signed contracts, identity documents, board minutes: the categories of paper most often scanned are exactly the categories that should not be uploaded to a stranger's server. When recognition happens in your browser tab, the question of what the vendor does with your document simply never arises.
The secondary benefits are practical. No page caps, because your CPU is the only meter. No queue, because you are the only job. No account, because there is nothing to bill. And once the engine and its language data are cached, the tool works offline — on a plane, in a basement archive, on an air-gapped machine.
Eight languages, on demand
Recognition models are script-specific: a model tuned for English guesses badly at Chinese. The tool ships language data for eight languages — English, German, French, Spanish, Italian, Portuguese, Simplified Chinese, and Japanese — and downloads only the one you select, keeping the first-load cost proportional to what you actually use.
Picking the right language matters more than any other setting. A German document recognized with the English model loses its umlauts to guesswork; a Chinese page under a Latin model produces noise. Mixed-language documents are the known hard case: choose the dominant language and expect to proofread the minority passages.
Honest quality expectations
Clean printed text is the happy path: a crisp 300-dpi scan of a laser-printed page recognizes at near-perfect accuracy, and the Markdown you get back is genuinely usable. Degradation follows predictable lines — low-resolution captures, skewed pages, faint photocopies, and decorative fonts each cost accuracy, and handwriting remains beyond any mainstream engine's reliable reach.
Two failure modes deserve special vigilance. Visually confusable characters — capital I, lowercase l, digit 1, digit 0 and capital O — misread silently, so numbers and names deserve a manual pass. And tables are the structural weak point: OCR reads cell text in reading order but reconstructs no grid, so a recognized table arrives as lines of text that you re-table yourself. OCR output is a draft, and treating it as one is the difference between a workflow and a mess.
Getting the best result from local OCR
Input quality is the largest lever you control. Scan at 300 dpi or better, keep the page flat and upright, and prefer the scanner's grayscale or black-and-white mode over a phone photo when you can. Photographing a document instead? Even light, no shadows across the text, and the camera square to the page recover most of the difference.
In the tool itself: select the document's actual language, run a page or two first to sanity-check accuracy on a representative sample, and proofread the numbers before the text goes anywhere downstream. Five minutes of spot-checking is cheap insurance against the one misread digit that matters.
When a desktop OCR tool is still the right choice
Local browser OCR is the right answer for the documents people actually have: a contract, a chapter, a stack of meeting notes, a scanned letter. It is not the right answer for every job. Digitizing an archive of ten thousand pages belongs on a machine you can leave running overnight, with a pipeline like ocrmypdf batch-processing folders unattended.
Layout-heavy documents argue for desktop tools too. If your pages are dense multi-column newsletters or forms where the spatial arrangement is the content, commercial engines with dedicated layout analysis — and the manual zoning tools that come with them — will outperform any in-browser pipeline. The honest summary: for everyday scans, local OCR in the browser is free, private, and good; for industrial volume or pathological layouts, bring heavier machinery.