BrowserTools
Home / Images / Image to Text (OCR)

Image to Text (OCR)

Extract the text from screenshots, scans and photos in your browser. Free OCR in five languages, batch friendly, with copy, .txt and .zip output and no uploads.

Loading Image to Text (OCR)… If nothing happens, please enable JavaScript.

Optical character recognition, OCR for short, is the process of turning a picture of text back into text you can select, search and edit. This tool does it with Tesseract, the OCR engine Google has maintained as open source since 2006, compiled to WebAssembly so it runs inside your browser instead of on a server. Drop in a screenshot, a scanned page, a photo of a receipt or a slide from a presentation, choose the language, and you get plain text you can copy, download as a .txt file, or paste straight into a document. You can queue several images at once and they are read one after another.

Frequently asked questions

Are my images uploaded to a server?
No. The OCR engine runs inside your browser as WebAssembly, so the image is processed locally and never leaves your device. Nothing is stored and nothing is logged. That is the main reason to use this rather than an online OCR service if your images are receipts, contracts, ID documents or anything else you would rather not hand over.
Why is the first run slow?
The first time you extract text, your browser downloads the OCR engine (about 4 MB) and the data for the language you picked (0.7 to 3 MB). Both are served from this site, not from a third party, and both are cached afterwards, so every later run starts immediately and works even offline. Recognition itself then takes a few seconds per image, depending on its size and your device.
Which languages are supported?
English, Portuguese, Spanish, French and German. Pick the language that matches the text in the image, not your own interface language. Getting this wrong is the most common cause of bad results with accented text, because the engine uses the language model to decide between visually similar characters.
Can it read handwriting?
Not reliably. Tesseract is trained on printed type, so neat block capitals written with a dark pen sometimes come through, but cursive handwriting almost never does. If you need handwriting recognition, that is a different class of model and this is the wrong tool for the job.
Why is the extracted text full of nonsense characters?
Usually the characters in the image are too small: Tesseract wants text around twenty pixels tall or more. Rescan at 300 dpi, or crop and enlarge before trying again. The other frequent causes are a skewed or rotated image, a shadow or glare across the page, light text on a dark background, and picking the wrong language. Switching the page layout to single block after cropping tightly often fixes a stubborn image.
What does the confidence score mean?
It is the engine's own average certainty across the words it recognised, from 0 to 100. Above roughly 90 the text is usually clean, in the 70s and 80s expect a few wrong characters worth proofreading, and below 70 the image itself is the problem rather than the engine. Treat it as a hint to check the result, not as a guarantee either way.
Which image formats can I use?
Anything your browser can decode: PNG, JPEG, WebP, BMP, GIF and usually AVIF. Screenshots pasted from the clipboard as PNG are the ideal input because they are lossless and already at screen resolution. Heavily compressed JPEGs lose the fine edges of small letters, so prefer PNG when you have the choice.
Can it read a scanned PDF?
Not directly, this tool takes images. If your PDF has real text in it, use the PDF Extract Text tool instead, which is faster and exact. If it is a scan, export or screenshot the pages as images first and run them through here as a batch.
Does it keep the layout, tables and columns?
Only loosely. The output is plain text with line breaks roughly where the engine saw them, and reading order follows what the page layout setting expects. Multi-column pages usually come out in the right order on the automatic setting, but tables lose their alignment and become lines of text. If a table matters, crop and read it column by column.
How many images can I process at once?
As many as you like, up to 25 MB per file. They are queued and read one at a time, since OCR is CPU-bound and running several at once would only make each of them slower. Each file gets its own text box, copy button and .txt download, and with two or more results you can download everything as a single .zip.

About Image to Text (OCR)

Two settings decide most of the outcome. The language matters more than people expect, because Tesseract does not just match shapes, it also weighs which letter sequences are plausible in the language you picked. Reading Portuguese or Spanish text with the English model is the single most common reason accented characters come out mangled, so pick the right language first. The page layout setting tells the engine what kind of arrangement to expect: automatic handles a normal page with paragraphs and columns, single block is best when you have cropped tightly around one piece of text, single line suits a serial number or a code, single word is for one label, and sparse text is the one to reach for when words are scattered across an image, as in a diagram, a map or a game screenshot.

Input quality sets the ceiling on accuracy, and resolution is the main lever. Tesseract likes characters that are roughly twenty pixels tall or more, which is why a crisp screenshot usually comes out perfect while a photo of the same text taken from across a room does not. Straight, evenly lit, high-contrast dark text on a light background is the ideal case: printed documents, screenshots, subtitles, book pages, invoices, forms and slides all work well. Perspective distortion, shadows falling across the page, motion blur, decorative or heavily stylised fonts, dense tables and handwriting are where OCR struggles, and no engine that runs on your phone will read cursive handwriting reliably. If a result looks poor, crop closer to the text, rotate the image upright, rescan at 300 dpi, and only then blame the engine.

Everything happens on your device. The engine itself, roughly 4 MB of WebAssembly, and the language data, between 0.7 and 3 MB depending on the language, are downloaded from this site the first time you run OCR and then cached by your browser, so later visits start instantly and work offline. Your images are never uploaded, nothing is stored and nothing is logged, which is the practical difference between this and the many online OCR services that ask you to hand over a contract, a passport scan or a medical form. Each result comes with a confidence score so you know whether to trust it at a glance, and with several files loaded you can download every extracted text as a single .zip.

A Hundred Years of Reading Machines

The idea of a machine that reads is older than the computer. In 1913 the physicist Edmund Fournier d'Albe built the Optophone, a device that scanned a printed line and turned it into musical tones so that blind readers could hear the shape of the letters. It worked, after a fashion, at about one word per minute. In 1929 Gustav Tauschek patented a machine that compared printed characters against metal templates with a photodetector, and in 1931 Emanuel Goldberg filed a statistical machine for searching microfilm archives by pattern. None of them recognised text in any general sense, but they established the trick every OCR system still uses: shine light at a page and measure what comes back.

The commercial breakthrough came from an unexpected direction. In 1974 Ray Kurzweil founded a company to build omni-font OCR, software that could read any typeface rather than one it had been tailored to, and the first customer he had in mind was not an office but a blind reader. The Kurzweil Reading Machine of 1976 combined a flatbed scanner, OCR and a speech synthesiser into a single desk-sized appliance. Stevie Wonder bought one of the first units and stayed a customer and friend of the company for decades. Around the same time the US Postal Service began deploying OCR to sort mail by reading addresses, which remains one of the largest OCR deployments ever built.

Tesseract, the engine behind this page, has a history that reads like a small miracle of software preservation. It was written at Hewlett-Packard's Bristol lab between 1984 and 1994, was judged accurate enough to place near the top of the 1995 UNLV accuracy tests, and was then shelved when HP left the market. It sat unused for a decade. In 2005 HP released the code as open source, and in 2006 Google took over maintenance, eventually rewriting the recognition core around LSTM neural networks in version 4. The result is that a program originally compiled for 1980s HP workstations is now the default OCR engine of the open-source world, and, compiled to WebAssembly, runs inside a browser tab on a phone.

One detail explains most OCR frustration. The engine does not read letter by letter in isolation, it combines the shapes it sees with a language model of which sequences are plausible, exactly as you do when reading bad handwriting. That is why the same image gives different results in different languages, why proper nouns and serial numbers are harder than ordinary prose, and why the classic OCR error is a word that is wrong but pronounceable. It is also why the letters that trip machines are the ones that trip humans: 0 against O, 1 against l against I, rn against m, and cl against d.

Support