Image to Text Converter

What this OCR engine is good at

This page runs tesseract.js, the browser build of the Tesseract OCR engine, in its neural network mode. That matters because it sets realistic expectations. Tesseract was built to read printed documents, and that is where it still performs best.

Things it handles reliably:

• Screenshots of web pages, error dialogs, terminal output and chat apps. Text rendered by a computer is perfectly formed and evenly spaced, which is the easiest possible input.
• Flatbed scans of printed pages at 300 DPI in a common serif or sans face such as Times, Georgia, Arial or Helvetica.
• Book pages, invoices, forms and printed letters photographed square-on in decent light.
• Product labels and signage with large, high contrast lettering.

What it gets wrong, and why

Handwriting. Essentially always. Tesseract is trained on typeset glyphs, and cursive or even neat printing rarely produces anything usable. If the image is a handwritten note, this is the wrong tool and no setting will rescue it.

Photographs taken at an angle. A page shot from above and slightly to the side has keystoned lines. The engine assumes rows of text run horizontally, so a skew of more than about five degrees starts shredding accuracy.

Low contrast. Grey text on a grey background, faded receipt thermal paper, or a phone screen photographed with glare. Binarisation has to decide what is ink and what is paper, and when the histogram has no clear gap it guesses badly.

Multi-column layouts. Newspaper and academic paper columns often get interleaved, so you end up with the first line of column one followed by the first line of column two. The text is all there, just in the wrong order.

Decorative and condensed fonts. Script faces, heavy display fonts, and anything with letters touching each other. Also very small type: below roughly 10 pixels of cap height, characters do not carry enough detail.

Tables. You get the cell contents as a stream of lines with no column structure preserved.

A worked example

Take a 1200 by 900 photo of a printed invoice, shot handheld under a ceiling light with a slight tilt. A typical result has an average confidence around 78 per cent, with the body lines correct but the dollar figures unreliable: 1,450.00 comes back as l,45O.OO because the engine confuses one with lowercase L and zero with capital O in that font.

Re-shoot the same invoice flat on a table, phone parallel to the page, in daylight, and the same crop comes back near 92 per cent with the numbers intact. Nothing about the tool changed. The input did.

Practical ways to get a better result

In rough order of how much difference they make:

Get the camera parallel to the page. This is the single biggest factor. Rest the page flat and hold the phone directly above it.

Crop to just the text block before extracting. Margins, staples, desk background and a hand holding the page all give the layout analyser things to misinterpret. Use Crop Image to trim first.

Aim for roughly 300 pixels per inch of the original page. A full A4 page wants to be about 2480 pixels wide. Shooting a whole page at 800 pixels wide will not work, and upscaling afterwards does not add detail.

Get even light. Move so the window is behind you, not behind the page, and avoid a single harsh lamp that throws a bright hot spot across half the text.

Split multi-column pages into single columns before running them, one column per image. Image Splitter does this quickly.

For a scanned PDF rather than a photo, convert the pages to images first with PDF to JPG, then bring them here.

Languages, batches and what comes out

The language dropdown covers English, Spanish, French, German, Italian and Portuguese. Choosing correctly matters more than it looks: the engine uses a language model to resolve ambiguous glyphs, so running French text under the English model produces accented characters mangled into their unaccented neighbours. Each language pack downloads on first use for that language.

Add several images and they are recognised one after another. With more than one image, each block in the output is preceded by a line reading the file name between dashes, so you can tell the pages apart. The combined text lands in an editable box, which is deliberate: the fastest workflow is to fix the handful of wrong characters right there before you copy.

Underneath, an average confidence percentage is reported across everything you ran. Treat it as a triage signal. Above about 90 you can usually skim. Below 75, read every line. Then copy to clipboard or download as extracted-text.txt.

If you want statistics on what you pulled out, paste it into Word Counter.

Honest limits compared with desktop software

Paid OCR packages do things this page does not: automatic deskew and despeckle, page segmentation that preserves tables, PDF output with an invisible text layer behind the original scan, and models trained on handwriting. If you are digitising a filing cabinet, buy one of those. If you need the text out of a screenshot or a few pages without sending your documents to anyone, this is faster and it is free.

The engine and language data are fetched the first time you click Extract Text, which is why the first run is slower than the ones after it. Everything runs in your browser, so your files never leave your device.

Common questions

Can it read handwriting?

No. Tesseract is trained on printed type. Handwritten notes, signatures and cursive come back as nonsense regardless of image quality, and there is no setting that changes this.

Why did my table turn into a jumble?

Layout analysis reads in lines, so cells are emitted as a text stream without column structure. For tabular data, crop each column separately and run them one at a time, then reassemble.

What resolution should I scan at?

Around 300 DPI for normal body text. Going to 600 DPI rarely improves accuracy and makes processing noticeably slower. Below 200 DPI accuracy falls off sharply.

Why is the first extraction slow?

The OCR engine and the language data for your chosen language are downloaded on first use and cached by the browser. Later runs skip that step. Switching to a language you have not used before triggers another download.

Does it keep line breaks and formatting?

Line breaks from the original are generally preserved, but bold, italics, font sizes, columns and indentation are not. The output is plain text only.