Image to Text (OCR)
Pull the text out of a photo, screenshot or scan and turn it into words you can edit, copy and search. The OCR engine runs entirely in your browser, so your image never leaves your device.
Quick answer: Yes — drop images or a PDF in and the text comes back editable, without any of it leaving your device. Pick the language, press Extract text, then copy it or download .txt, .md or .docx. Several files at once, PDFs included, and no size limit.
- Can it read a PDF?
- Yes — drop the PDF in and every page is rendered and recognised. A page range like
1-3, 7reads only those pages. - Can I do several files at once?
- Yes. Drop as many images as you like, mixed with PDFs. Each is listed with its own result, and one unreadable file never stops the rest.
- Is there a file-size limit?
- No. The work happens on your device, so there is nothing to meter — where the free tiers that upload cap you at 3 MB to 10 MB per file.
- Which languages work?
- 35, grouped by script. Measured on our own fixtures: English and German came back at 100%, and Arabic — right-to-left — also at 100%.
- Is my image uploaded?
- No. The recognition engine is WebAssembly running inside the page. Only the engine and the language data are fetched, once, and cached.
- What can I download?
- Plain
.txt, Markdown.md, or a real Word.docxbuilt with actual paragraphs — not a .txt with the extension changed. - Can it read handwriting?
- No. This engine is built for printed and typed characters; neat handwriting sometimes works and cursive does not. It is better to know that than to be surprised by it.
What this OCR tool supports
| Capability | Supported | Detail |
|---|---|---|
| Input | ||
| JPG, PNG, WebP | Yes | A photo, a screenshot or an export. |
| GIF and TIFF | Yes | Common scanner output. |
| Yes | Every page rendered and recognised; a page range is accepted. | |
| Several files at once | Yes | Images and PDFs mixed. Each gets its own result. |
| File-size limit | No | None. Nothing is metered because nothing runs on our machines. |
| Handwriting | No | Printed and typed characters only. |
| Languages | ||
| 35 languages | Yes | Latin, Cyrillic, Greek, Hebrew, Arabic, CJK and Indic scripts. |
| Right-to-left | Yes | Arabic, Persian and Urdu. Measured at 100% on an Arabic fixture. |
| Two languages at once | Yes | For a page that mixes them, e.g. English + Chinese. |
| Automatic language detection | No | You pick the language. Guessing it wrong costs more than choosing it. |
| Output | ||
| Plain text (.txt) | Yes | Joined paragraphs, or line breaks kept — your choice. |
| Markdown (.md) | Yes | Each source file becomes a heading. |
| Word (.docx) | Yes | Real paragraphs via the docx library, not a renamed .txt. |
| Copy to clipboard | Yes | The whole result, or edit it in the box first. |
| Searchable PDF | No | Not built. The text layer would have to be written back into the PDF. |
| Tables and layout | No | Text only. For a table, use the PDF table extractor. |
| Processing | ||
| Runs in your browser | Yes | WebAssembly. The image and its text never leave the device. |
| No account, no signup | Yes | |
| No watermark | Yes | |
| Free | Yes | No page count, no daily quota. |
| Works from cold with no network | No | The page and the engine (~6 MB, once) have to load first. |
The No rows are there on purpose. A capability stated falsely is worse than one not stated.
35 languages, and what we actually measured
Most free OCR sites quote a language count and leave it there. We ran the shipped engine against fixtures we rendered ourselves, so the text going in was known exactly and the text coming out could be scored character by character.
| Language | Characters correct | Ignoring spacing | Language data |
|---|---|---|---|
| English | 100% | 100% | 2.82 MB |
| German (with umlauts) | 100% | 100% | 1.27 MB |
| Arabic (right-to-left) | 100% | 100% | 1.58 MB |
| Chinese (Simplified) | 41% | 84% | 1.64 MB |
The Chinese row is the interesting one, and the first number is misleading
Look at what actually came back: 发 票 总 额 where the fixture said 发票总额. Every character is right. Tesseract inserts a space between each CJK glyph, and a plain character-distance score counts each of those as an error — which is how a correct reading lands at 41%. Ignore the spacing and the same output scores 84%.
So the tool fixes it rather than reporting it: Tidy CJK spacing removes a space only where it sits between two CJK characters, leaving ordinary spacing in Latin text on the same line alone. You can switch it off and see the raw engine output.
Two honest limits on this table. It is four languages, not thirty-five — the rest are offered because the engine supports them, not because we have scored each one. And a rendered fixture is a clean one: a photograph of the same text will do worse, which is what the next section is about.
Several files, and PDFs
Drop as many images as you like, mixed with PDFs. Each file is listed with its own status and its own result, and one file that cannot be read never stops the rest — it is marked failed and named, and the others still come through. A batch that reports only a total hides the one file that went wrong.
For a PDF, every page is rendered and recognised; put 1-3, 7 in the page box to take only those. Pages are rendered at just under 3× before recognition, which is where accuracy plateaus — bigger than the detail the page actually contains magnifies the blur rather than revealing anything, and it costs memory a phone may not have.
One worker handles the whole batch. Starting a fresh one per file re-initialises the engine and re-reads the language data every time, which on a ten-image batch is most of the wall clock.
What you can take away
Four things, from the same result: copy it, .txt, .md with each file as a heading, or .docx. The Word file is built with the docx library as real <w:p> paragraphs — several converters hand back a text file with the extension changed, which opens with a warning and carries no structure at all.
The text lands in an editable box first, so a stray character is quicker to fix there than in Word afterwards. Plain text joins the lines within a paragraph and keeps the blank line between paragraphs; Keep line breaks leaves the engine's own line endings, which is what you want for a poem, an address block or a code listing.
Getting a good read
Accuracy is decided almost entirely by the image, not by the engine. In rough order of how much each one costs you:
- Resolution. Characters need pixels. A screenshot enlarged before capture beats the same screenshot shrunk to phone width and re-compressed by a chat app, which can arrive with characters a few pixels tall — nothing downstream recovers that.
- Focus and glare. A blurred photograph cannot be un-blurred. Tap to focus, and move rather than using flash, which replaces one problem with a bright centre and dark corners.
- Straightness. Shoot square to the page. Rotation costs real accuracy, and perspective is not corrected here.
- The right language. Picking the wrong one is worse than it sounds: the engine is matching character shapes against that language's model.
- Crop to the text. A photo of a desk spends most of its pixels on the desk.
If your phone has a document scanner — Notes on iPhone, Google Drive on Android — run the page through it first. It corrects the perspective, flattens the lighting and gives you a PDF, which this tool now takes directly.
Where your image goes, and where it does not
Nowhere. The engine is compiled to WebAssembly and runs inside the page, so a payslip, an ID or a private screenshot is read on your own machine. You can check rather than trust it: open the Network tab and watch while you extract — no request carries your file.
Being straight about two things. We are not the only browser-based OCR — PortImg runs Tesseract.js in the page as well, though with English and Hindi. And the engine and the language data are fetched from a CDN the first time, about 6 MB, then cached by your browser; that request reveals which language you picked, and nothing else.
What the local approach removes is the queue and the cap. Free tiers that upload have to meter: OCR.space allows 5 MB a file, DocsJam 3 MB and 3 pages, and several others 10 MB (checked September 2026). There is no equivalent number here because there is no server to protect — the limit is your own device's memory.
When this is the wrong tool
- The PDF already has real text. Try selecting a word in a reader: if it highlights, the characters are in the file and OCR can only make them worse. Use PDF to text, which is exact.
- You want the table, not the words. OCR returns a stream of text; which number belonged to which column is exactly what it throws away. The PDF table extractor keeps the columns, and does its own OCR for scans.
- It is handwriting. Effectively unreadable rather than merely inaccurate — worth knowing before you photograph forty pages.
- You need a searchable PDF back. Not built here; this gives you the text, not a rewritten PDF.
- The image is tiny. Recapture it larger. It is the one input problem with no software fix.
How image-to-text OCR works
The tool runs Tesseract, a mature open-source OCR engine, compiled to WebAssembly so it works right in your browser. When you click Extract text it scans the image, finds the letters and numbers, and reconstructs them as real editable text — the same technology that makes a scanned page searchable. Because it runs on your device, a receipt, an ID or a private screenshot is never sent to a server.
Accuracy depends mostly on the image: sharp, well-lit, straight text reads best, which is why screenshots and flatbed scans are near-perfect while a blurry photo at an angle is harder. Choosing the right language matters too, since it tells the engine which characters and words to expect. Once the text is out, you can fix any stray character in the editable box, then copy it or download it as a .txt file.