Image to Text

What is an image to text converter?

An image of text is not text. A screenshot of an error message is a grid of coloured pixels that happens to look like words, and nothing in it can be searched, selected, or pasted. Optical character recognition is the step that reverses that: it finds the shapes in the bitmap that resemble characters, decides which character each one is, and hands back a string. The name is old enough to predate the web, but the problem has grown, because more of what gets shared now is a picture of writing rather than the writing itself.

Drop an image on this page, choose the language it is written in, and the extracted text appears below it with a character count, a word count, and a confidence score. Ten languages are available, including Chinese, Japanese, Russian, and Arabic. The result is plain text you can copy or download as a .txt file. Recognition runs inside your browser tab, so the image is never sent anywhere.

When to use it

Screenshots are the reason most people arrive. Someone pastes a stack trace into Slack as a PNG and you need the exception name in a search box. A PDF viewer refuses to let you select the paragraph you want to quote. A vendor sends the API key in a picture of their terminal. The text exists, it is right there on screen, and the one thing you cannot do is copy it. Drop the screenshot here and you get the characters back.

The second case is paper. A receipt you need the total from, a printed invoice going into a spreadsheet, the page of a contract that has to be searchable, a whiteboard after a meeting, a business card. Photograph it with a phone, drop the photo in, and the typed portions come back as text. Print reads far better than handwriting, so a printed receipt will do well and the note scrawled across the bottom of it will not.

Then there is everything published as a picture on purpose: infographics, conference slides exported as JPGs, scanned pages from a book, screenshots of tables in a report. If the image itself also needs work, the Image to WebP and Image to Format tools on this site convert and compress it; this one only reads what is written on it, and leaves the file alone.

How this tool works

Recognition is done by Tesseract, the OCR engine Google has maintained since 2006, compiled to WebAssembly and running in your browser. It arrives in pieces, and none of them until you ask for text. A small loader script of around 63 kB and the engine core of roughly 5 MB both download the first time you extract anything, so opening this page and leaving costs nothing. Each language is a separate trained model of a few megabytes more, fetched the first time that language is selected, which is why switching from English to Japanese triggers a wait the second English image does not. All of it is cached by the browser afterwards, so the cost lands once. The progress bar names the phase it is in rather than showing an unlabelled spinner, because on a large page the whole sequence can run twenty or thirty seconds and a silent wait is indistinguishable from a hang.

What comes back is characters, not layout. OCR reads glyphs; it does not record that a heading was bold, that a figure was in the third column, or that two blocks of text were side by side. Bold, italics, colour, and font size are gone. A table arrives as its cell contents run together. A two-column page can interleave the columns, because the engine reads across the image and the columns are, geometrically, the same lines. This tool returns plain text and does not try to infer structure, which is a deliberate limit: a guess at formatting that is right most of the time is worse than no guess, because you stop checking.

Accuracy depends almost entirely on the image, and the things that hurt it are predictable. Typed text reads well and handwriting reads badly. Resolution matters more than file size, so a 200-pixel-wide crop of a paragraph will fail where a photograph of the whole page succeeds. Low contrast hurts: light grey on white, or text over a photograph. So do unusual display fonts, heavy compression artefacts, glare, and a page photographed at an angle. Straightening the image and cropping to the text before uploading is the single most effective thing you can do. The confidence figure shown with each result is the engine's own mean score across the words it read, on a scale of 0 to 100. Above 85 the output is usually clean. Between 60 and 85 it is worth proofreading, digits and punctuation first, since a 0 read as an O will not look wrong to you. Below 60, treat what you get as a draft.

Choosing the right language is not a formality. The model carries the alphabet, the character shapes, and a dictionary the engine leans on when a glyph is ambiguous, so running Russian text through the English model returns little that is useful. Chinese and Japanese need their own models for the obvious reason, and Arabic is read right to left. If a result comes back far worse than the image looks, check the language selector before blaming the photograph.

Nothing you drop here is uploaded. The image is read from your own disk into the page, passed to the WebAssembly engine in the same tab, and never crosses the network. No request this page makes carries your image. The engine and the language model come from a public CDN, and the page furniture — the web font and the site imagery — comes from where it does on every page here; none of it has seen what you dropped in. That distinction matters more for OCR than for most tools on this site, because the images people need read tend to be the ones they cannot paste into an online service: a signed contract, a medical letter, an invoice with account numbers on it, a screenshot of an internal dashboard.

Frequently asked questions

• Which languages does this OCR tool support?

  Ten: English, Spanish, French, German, Portuguese, Italian, Chinese (Simplified), Japanese, Russian, and Arabic. Pick one before extracting, and pick the one the document is written in, because each is a separate trained model rather than a setting. The model downloads the first time you use that language and is cached afterwards, so the wait happens once per language and not once per image. Mixed-language documents are read with whichever model you chose, so a mostly-English page with a few French names will do fine, and a page split evenly between two scripts will not.

• Why does the formatting not come through?

  Because OCR recognises characters, not layout. The engine works out which glyph each shape is; nothing in that process records that a line was a heading, that a run of text was bold, or that the page had two columns. So you get the words and lose the styling, tables flatten into their contents, and side-by-side columns can interleave. This tool returns plain text rather than guessing at structure, on the grounds that formatting which is right most of the time is more dangerous than formatting that was never claimed, because you stop checking it. If layout matters more than the text does, a PDF with a real text layer is the better starting point.

• How accurate is OCR?

  On a sharp, straight, well-lit image of printed text, high enough that you will be correcting punctuation rather than retyping. On a phone photo taken at an angle in poor light, low enough to be worth checking line by line. The variables are resolution, contrast, and how ordinary the typeface is, and every result here carries the engine's own confidence score so you are not guessing which situation you are in. Above 85 percent is usually clean; below 60, treat it as a draft. Cropping to the text and straightening the page before uploading helps more than anything else.

• Can it read handwriting?

  Poorly, and you should not plan around it. Tesseract is trained on printed type, where a given letter has a consistent shape, and handwriting breaks that assumption in a different way for every writer. Neat block capitals sometimes come through. Cursive rarely does. A form with printed labels and handwritten answers usually returns the labels cleanly and the answers as noise, which is worth knowing before you photograph two hundred of them.

• Is my image uploaded anywhere?

  No. The file is read from your disk into the page and handed to a WebAssembly engine running in the same browser tab. There is no server behind this page to receive it, no request carrying it, and nothing logged. Nothing that leaves this page carries your image. The OCR engine and the language model are downloaded from a public CDN, and they travel one way. Since the documents people need read are often the ones they cannot paste into an online service, that is the property the tool was built around rather than a footnote to it.

• Can we get this running over our own documents?

  Yes, and it is a common ask. A page like this one handles the screenshot and the receipt. It stops being the answer once there is a folder of ten thousand scanned invoices, a mailbox where every attachment needs reading, or a requirement that extracted values land in a database with the fields already identified. That is the point where OCR stops being a tool and becomes a pipeline, usually with layout analysis and validation around it. Zinc Online Solutions builds those. Tell us what the documents are and where they arrive from, and we will tell you what it takes.