Free Online OCR: How to Get Text Out of a Screenshot, Photo, or Scan

The short answer: for clean, printed text this problem is solved — and it is free. Your phone pulls text off a photo with no app at all. A browser page does it in seconds. An offline app does it by the folder with nothing ever uploaded. What still bites in 2026 is a narrower list: handwriting, tables, and two members of the punctuation family — spaces and pipes. Extract first; proofread second. This page is about both halves.

Three free routes, fastest first

Your phone. Modern phone systems read text straight off a photo or screenshot: open the picture, select, copy. Nothing leaves the device, and for the ordinary case — a sign, a receipt, a page — the result matches what any website will hand you. Start here.

A browser converter. Search "image to text" and you get dozens of pages that all work the same way: upload, wait, copy. Two habits keep them safe. Favor converters that run the recognition inside your browser — a well-built one loads a few megabytes once, then keeps working with the network off. And never hand a random site something you would not mail: IDs, contracts, medical pages.

An offline app, for volume. Free open-source apps from the Tesseract lineage chew through folders and scanned PDFs, and stay offline after a first run that downloads language data — tens of megabytes, once. Budget a few seconds per page on an ordinary CPU. (A scan is just a picture, so a scanned PDF gets read page by page.)

And the oldest rule still leads: garbage in, garbage out. OCR reads pixels, not intentions. Sharp beats blurry; flat beats wrinkled; lamp-lit beats glare. Nothing further down this page rescues a photo that is already illegible to your own eye — if the output is nonsense, reshoot before you blame the tool.

What keeps breaking: handwriting, and the score nobody explains

A recent hands-on test fed handwritten command lines to two cloud OCR engines, and the numbers it produced tell two different stories.

• One handwritten line came back at 95.8% character accuracy — 23 of 24 characters correct.
• Across the full set, character accuracy settled at 71% for the high-precision engine and 73.2% for the handwriting-specific one.
• Then the scoring changed from "are the characters right" to "is the line fully correct," and the same engines scored 3.3% — one line in thirty — and 10%.

That last pair is the honest number for handwriting. Character scores forgive scattered mistakes; usefulness does not. For anything you will execute or paste onward — a command, a serial number, a line of code — only the whole-line score matters, and it is an order of magnitude worse than the number on the box.

The characters that carry the meaning

The same test logged what actually gets lost, and the ranking is lopsided.

• Spaces, by a mile. The miss tally: space 70 times; the runner-up, 13. ls -la came back as ls-la — every letter present, the line dead.
• The pipe never made it. Ten lines, two engines, zero survivors. Four times it was read as a capital "I" — so cat log.txt I grep error runs without complaint and quietly does the wrong thing.
• Swaps that stay plausible. rm came back as vm; /tmp became ltmp. Each output looks executable. Each is a different command.

Which gives the sorting rule for reviewing any OCR output: the words are usually fine; the glue is not. Read the separators, the gaps, the punctuation — that is where meaning leaks.

What keeps breaking: tables

Another evaluation ran real-world tables — statistics reports, financial pages, colored dashboards — through the leading multimodal models, scoring structure and every cell. Best result: 66%. Most of the field: 56–63%. Read that as: the winner still mangled about one table in three. The failure patterns repeat.

• Multi-level headers collapse. Merged header cells get split into separate rows, and the hierarchy beneath them crumbles — the most frequent failure of all.
• Watermarks eat cells. Under a semi-transparent watermark, output went blank or filled with dashes — content silently deleted.
• Numbers drift. One value, -4.2, came back as -1.2. Structure perfect, digit wrong: the hardest kind of error to notice.
• First and last rows get reclassified. Nearly every model peeled the table's first row off as a "title" and its final row as a "footnote."
• More thinking did not help. A step-by-step reasoning mode scored below the plain mode of the same model, 61 versus 63, and a small sibling outscored its pro sibling. Perception work does not reward deliberation.

If the numbers matter, the only honest route is cell-by-cell against the original.

A three-minute check before you trust the text

1. Separators first. Pipes, slashes, hyphens. Remember: zero pipes survived ten tries.
2. Gaps second. Spacing is the top casualty in the loss logs; ls-la is not a command.
3. Numbers third. Read every figure you plan to use, digit by digit.
4. Tables: cell by cell, or not at all. Nothing in the evaluation got close to "just trust it."
5. Keep the original until all four checks pass — after that, the photo is just storage.

Fine print worth knowing

• Free online tiers are meters; they reset, move and vanish. Check today's terms, not last year's blog post.
• Offline apps download language data on first use — tens of megabytes, once — then work with the cable unplugged.
• One quirk of that offline world: a compressed "integer" language file (about 1.6 MB) gets refused by newer OCR engines with a Failed loading language error. Swap in the full-size file (Chinese runs about 19 MB); the compact build is the one that fails.
• Handwriting, tables, symbolic text: budget corrections. Clean printed body text: near-perfect.

Extraction is cheap now. Trust is the scarce part — and the errors that hurt are the ones that look clean: the table that restored perfectly except for one digit, the command that ran just fine with an I where a | belonged. Read the separators, the gaps, the numbers. Then delete the photo.