Extracting text from an image

Where PNG came from, and why it is like this

Every other conversion here rearranges data that is already present. This one manufactures data that is not.

An image of a page contains no text — it contains pixels that happen to be arranged in the shape of letters. Optical character recognition looks at those shapes and guesses which characters they are. The engine used here, Tesseract, began at Hewlett-Packard in the 1980s, was open-sourced in 2005, and now runs compiled to WebAssembly inside the browser tab. It is genuinely good and it is genuinely guessing, and no amount of processing makes the second part stop being true.

Is this conversion lossy?

The question does not quite apply, because nothing is being converted — something is being read. What matters instead is accuracy, and accuracy varies enormously with the input.

Clean, high-resolution, high-contrast printed text in a common font produces excellent results. Accuracy degrades with low resolution, skewed or curved pages, unusual fonts, coloured or textured backgrounds, and photographs taken at an angle. Handwriting is essentially not recognised by this engine.

The failure mode matters as much as the rate: OCR does not usually return an error, it returns confident nonsense. A misread digit in a table of figures looks exactly like a correct one. Anything that matters has to be checked against the image.

What happens to metadata, transparency and colour

Layout does not survive. The output is a stream of text. Columns, tables and text boxes are read in the order the engine works through the image, which for multi-column pages frequently interleaves the columns.

Formatting does not survive. Bold, italic, size and colour are visual properties the engine is not asked to record.

Image metadata is irrelevant — nothing from the source EXIF reaches a text file.

Resolution is the dominant variable. Recognition wants roughly 300 pixels per inch of original page. A screenshot at typical screen resolution is well below that, which is why OCR of small on-screen text is noticeably less accurate than OCR of a proper scan. Enlarging the image first does not help; the detail is not there to enlarge.

Why people actually need this

Something is only available as a picture. A screenshot of an error message that needs to be searched for, a photograph of a sign or a menu, a scanned page with no text layer, an image in a document where the text cannot be selected. The person can see the words and the computer cannot.

The second, quieter situation is accessibility: text locked in an image is invisible to screen readers, and extracting it is the first step to making it available.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

And the ceilings measured for OCR, the tool that performs it, on the hardware described on the limits page:

Not tested

The page also refuses files above 100 MB before it starts, which is a guard written into the tool rather than something the browser imposes. Why those are different.

When something else is the better answer

If a version with real text exists, use it. OCR is a reconstruction, and every reconstruction is worse than the original.

If the image is a table of numbers, reading it as a spreadsheet keeps the rows and columns that plain text destroys.

If the source is a PDF, check first whether it already has a text layer — extracting its text takes seconds, and if that works the result will be perfect where OCR would only be good.

If the text is handwritten, this engine will not read it, and no browser-based tool currently will.