Extract Text From an Image

Nobody arrives here caring about file formats. The task is concrete: there are words locked inside a picture, and they need to be somewhere you can edit, search, quote, or paste them. Maybe you are writing a report and the source is a photographed page. Maybe a reference number exists only in an image someone sent you and retyping it feels absurd. Maybe you are moving a list of names off an old flyer and into a spreadsheet. Whatever the errand, the mechanism is the same, and the tool above handles it without an account, a quota, or an upload. A recognition engine — Tesseract 7, served from this site as WebAssembly rather than fetched from someone else's cloud — runs inside this browser tab. The first run brings down the engine plus a language model of roughly 1.9 MB and keeps them in cache. After that the picture goes in and the words come out, on your own hardware, whether or not you have a connection.

Step one: get the picture onto the right machine

This sounds trivial and it is where most of the wasted time goes. Decide first where the text needs to end up, then move the image to that device before doing anything else. If the finished paragraph belongs in a document on your laptop, do the recognition on the laptop, because copying a long block of text between phone and computer is more friction than moving one file. If the words are going into a message you will send from your phone, keep the whole job on the phone. When you do transfer, prefer whatever route preserves the file rather than re-rendering it: a direct file transfer, a cloud folder, or an email attachment all keep the original bytes, whereas pasting an image into a chat window usually hands you a smaller, re-encoded version with softer letters. The tool accepts JPEG, PNG, WebP, AVIF, HEIC, BMP, GIF, and TIFF, so no conversion step is needed on the way; iPhone HEIC files and scanner TIFFs are decoded by the tool directly rather than relying on the browser to understand them.

Step two: give the engine only what you need

Recognition works on the whole frame, so everything in the frame becomes output. If you photographed one paragraph of a magazine spread, the caption, the pull quote, the page number, and half of the facing article will all appear in the result, interleaved in reading order, and you will spend longer picking your paragraph out of the pile than you would have spent retyping it. Cropping to the region you actually want is the single highest-value thirty seconds in this whole process. It also speeds the run up, since there is less picture to analyse, and it sidesteps the layout problem entirely: a single column of text comes back as clean prose, whereas a multi-column page comes back interleaved because plain-text output has no way to express two columns. Straighten anything that arrived sideways before you start too. Modest skew is tolerated; a ninety-degree rotation is not.

Step three: read the confidence figure honestly

Alongside the text you get a confidence percentage, and the useful way to treat it is as a proofreading budget rather than a grade. High confidence means skim it and move on. Middling confidence means the engine met something it found difficult — a soft region, a shadow, an unusual face — and you should expect scattered character-level slips, most often between shapes that genuinely look alike: zero and capital O, one and lowercase L, five and S, the pair rn reading as m. Low confidence means read every line against the original. Crucially, the engine always returns something. It does not decline. So a low figure is the only signal you get that the input was beyond it, and the failure mode is text that looks entirely plausible until you check it.

Step four: what to do with the text once you have it

The output is plain text, which means you are getting characters and not a document. Paragraph breaks generally survive; typographic styling does not, because the engine reports what the characters are rather than how they were set. So expect a short tidy-up. Hard line breaks from the original page will need rejoining into flowing paragraphs if the source was narrow, since the engine breaks lines where the page broke them, not where your sentences end. Hyphens splitting a word across two lines come through as literal hyphens and want closing up. If the words are headed for a spreadsheet, paste into a plain-text editor first and rebuild the delimiters by hand, because a table has already lost its column structure by the time it reaches you.

Then do the pass that actually matters: check the numbers. A misread word announces itself, because it will not be a word. A misread digit is invisible. An account number, a date, an invoice total, or a dosage that came through with one character wrong looks completely normal and will happily propagate into whatever you paste it into. Verify every figure against the picture, every time, regardless of what the confidence said.

When recognition is the wrong instrument

Four situations where you should stop and do something else. The text is already selectable. A great many PDFs, and every ordinary web page, contain real text under what looks like an image; try dragging a cursor across it before reaching for any tool. The source is handwritten. The model was trained on typeset and rendered characters. Tidy block capitals sometimes survive, but everyday joined-up writing produces fluent nonsense, and no amount of image quality changes that. The document is not in English. Version one ships the English model only, with more languages coming, and a page in another language will still return output, which is worse than a refusal. You need a faithful reproduction. If layout, signatures, stamps, and page geometry are part of the meaning — a contract, a certificate, anything legal — the picture is the record and a text transcription is a convenience copy at best. Also worth knowing: this tool does not take PDF files as input today. It reads pictures.

Why doing it locally changes the calculation

The pictures people need words out of skew heavily towards the private: payslips, prescriptions, statements, identity documents, correspondence, internal screens. The standard web service model sends every one of those to a machine you do not control, and you would need to read a privacy policy to find out what happens next. Because the engine here executes in your browser, no request carrying image data is made at all, so the question does not need answering. That also removes the practical annoyances that come with the server model: no queue, no page-per-day cap, no email wall, and no upload to redo when a large file times out. Retrying with a better crop costs you nothing but the click. If you want the same engine framed around a particular kind of file, JPG to text goes into what compression does to letterforms, and screenshot to text covers the case where you were about to install an extension.