Image to Text Converter

What OCR does, and where it runs

Optical Character Recognition, or OCR, is the step that turns the shapes of printed letters inside an image into characters a computer can select, copy, and edit. This tool runs that step with Tesseract.js 7.0.0, a WebAssembly build of the Tesseract engine that Hewlett-Packard began in 1985, released as open source in 2005, and Google has maintained since 2006, now at major version 5. The important consequence is where the work happens: the engine is compiled to WebAssembly and runs inside your own browser tab, so the image itself is never uploaded. A bank statement, an identity card, a contract, or a private screenshot stays on your device from start to finish. The only thing that ever crosses the network is the language data file, and only the first time you pick 1 of the 10 languages. That single design choice, local recognition, is what separates this from the many converters that require uploading your document to a remote server before it can read a word.

The 4 steps inside a single pass

A recognition pass is not 1 action but 4 in sequence. First the engine binarises the picture, collapsing the 3 red-green-blue channels to 1 greyscale channel of 256 levels, values 0 to 255, and then to 2 tones, ink and paper, using Otsu adaptive thresholding. Second it analyses the page layout, finding the blocks, lines, and words. Third it segments each word into individual glyphs. Fourth it recognises each glyph with a Long Short-Term Memory neural network, the model behind Tesseract version 4 and later, which reads a whole line as 1 sequence rather than 1 isolated letter at a time, a shift added in version 4 around 2018. This tool selects engine mode 1, the Long Short-Term Memory path, because it is markedly more accurate on real-world text than the older pattern matcher from version 3, which matched each glyph against roughly 100 stored character shapes across about 60 fonts. The output is plain text, ready to drop into any editor, and this tool also reports a live word count once the pass finishes.

Why the first run is slow and the rest are fast

The first time you choose a language, the browser fetches that language data file, a trained model of roughly 10 to 15 megabytes for English and up to 20 for Chinese, from the content delivery network the library uses. That 1 download is the reason the first run feels slow, often 5 to 20 seconds on a typical 10 to 50 megabit connection. Once fetched, the browser caches the file in its storage, so every later run in that same language is far quicker, commonly 2 to 5 seconds, and needs 0 network access. The nuance worth stating plainly: offline use works only for languages you have already downloaded once. English will run offline after its first fetch, but the first time you switch to Hindi or Japanese, that new 10-plus megabyte model has to be fetched before recognition can begin. The tool ships 10 languages: English, Hindi, Spanish, French, German, Portuguese, Arabic, Chinese Simplified, Japanese, and Russian, covering 5 writing systems: Latin, Devanagari, Arabic, Cyrillic, and the roughly 3000 common Chinese-Japanese characters.

What raises and lowers accuracy

OCR quality is decided almost entirely by the input. Clean, sharp, high-contrast printed text photographed straight-on reads best, often at 95 to 99 percent character accuracy. Four things drag that number down: blur, skew past 10 or 15 degrees, low light, and a busy background. Choosing the wrong language matters just as much, because each model expects a specific character set and even a specific direction of text, whether left-to-right like English or right-to-left like Arabic. A page of English run under the Arabic model will produce nonsense. Two input types are genuinely hard: handwriting, which the printed-text models were never trained on, and decorative or stylised fonts, both of which routinely fall below 50 percent. For those, no amount of retrying the same image helps; a cleaner capture, or a service with a handwriting model, is the only fix. Accuracy also compounds with length: at 98 percent per character, a 1000-character page still carries about 20 errors, and at 95 percent that climbs to 50, which is why a quick proofread of the editable output is always worth the 30 seconds.

Where this saves real time

The payoff is measured in minutes. Retyping a 300-word printed page by hand takes 4 to 6 minutes, about 40 words a minute, and invites transcription slips; an OCR pass plus a 30-second proofread is closer to 1 minute, a 4x to 6x speedup that scales linearly. A stack of 20 pages that would be a 90-minute typing session becomes a 20-minute review, a 70-minute saving. The common jobs are familiar: lifting a quote from a screenshot, pulling an address off a photographed letter, capturing a code snippet from a conference slide, or digitising a handful of printed receipts. Because the editable text lands in a textarea, you can fix the 1 or 2 stray characters OCR missed before you copy it out, rather than discovering them pasted into a document later.

Getting a clean capture

Because every downstream step inherits the quality of the pixels, the capture is where accuracy is won. Photograph the page straight-on so the lines stay horizontal, since even a 5 to 10 degree tilt measurably hurts the line-finding step, and past 15 degrees it falls sharply. Fill 80 to 90 percent of the frame with the text rather than the desk around it, so more of the sensor lands on actual characters. Favour even, bright light and avoid glare, which the 2-tone threshold misreads as strokes. A flat, well-lit 8-megapixel phone photo, about 3264 by 2448 pixels, near 8 million total, of a printed page typically reads in 2 to 5 seconds after the model is cached. Digital screenshots are the easiest input of all, because their text is already pixel-perfect at 100 percent zoom and needs no thresholding guesswork; they often reach 99 percent in under 2 seconds.

Quick reference

• Engine: Tesseract.js 7.0.0, a WebAssembly build, running in your browser.
• Engine mode: 1, the Long Short-Term Memory path, more accurate than the version 3 pattern matcher.
• Privacy: the image is never uploaded; only the language file is fetched, once per language.
• Languages: 10, spanning 5 scripts from Latin and Devanagari to Arabic, Cyrillic, and Chinese-Japanese.
• First run: downloads a 10 to 15 megabyte model in 5 to 20 seconds, then caches it for offline reuse.
• Later runs: 2 to 5 seconds with 0 network access, in any of the 10 languages already cached.
• Accuracy: 95 to 99 percent on clean printed text; under 50 percent on handwriting.
• Best input: flat, sharp, well-lit printed text, or a digital screenshot at 100 percent zoom.
• Output: editable plain text with a live word count, copy-to-clipboard, and download-as-txt.