Upload a JPG, PNG or scanned PDF, extract the text with in-browser OCR, and download a fully editable Word, Excel, PowerPoint or text file. No upload, no limits.
or click to browse — PNG, JPG, JPEG, PDF supported
This free OCR tool turns a photo or scanned document into an editable file without uploading anything. Drop in a JPG, PNG or scanned PDF, and the built-in OCR engine reads the characters in the image so you can export them to Word, Excel, PowerPoint or plain text. Because everything runs locally with WebAssembly, your documents stay private and there is no upload limit.
It is built for students digitising notes, office workers retyping scans, accountants who need to extract a table from an image online, data-entry professionals, and developers who just want to copy text from an image for free. Convert image to Word, image to Excel, or JPG to Excel online free in a few clicks.
1) Upload your scan or photo. 2) Pick the output format (Word, Excel, PowerPoint or text). 3) Click Run OCR & Export and watch the status as the engine loads, analyses the layout and writes your document. 4) Review and edit the recognised text in the right-hand panel, then Download Editable File or copy the text to your clipboard.
Yes. The tool runs entirely in your browser using Tesseract.js, so there is no server and no per-file or per-day upload limit. Convert as many images as you like, for free.
Completely. Your images and scanned PDFs never leave your device. All OCR text extraction and document generation happens locally in your browser, so nothing is uploaded to any server.
Yes. The exported .docx, .xlsx, .pptx and .txt files are fully editable. You can open them in Microsoft Office, Google Docs, Google Sheets, or any compatible editor and change the text freely.
Yes. Choose the Excel (.xlsx) output and the recognised text is placed into spreadsheet rows and columns so you can clean up tabular data from a scan or photo.
You can upload JPG, JPEG, PNG and scanned PDF files. The tool reads the characters in the image and lets you export to Word, Excel, PowerPoint or plain text.
There is no hard server limit because processing is local. Very large or low-quality scans simply take a little longer to process, depending on your device.
Optical character recognition is a pipeline, and knowing the stages explains almost every failure you will encounter.
| Factor | Good | Poor |
|---|---|---|
| Text height | 20 px or more per character | Under 10 px |
| Effective resolution | 300 DPI equivalent | 72 DPI screenshot |
| Contrast | Dark text, plain light background | Grey on grey, text over photo |
| Skew | Under 2 degrees | Handheld at an angle |
| Typeface | Plain serif or sans-serif | Script, decorative, condensed |
| Focus | Sharp throughout | Motion blur, shallow depth of field |
The single biggest lever is character height in pixels. A photo of an A4 page taken so the page fills the frame on a 12-megapixel phone camera comfortably exceeds 300 DPI equivalent. The same page photographed from across a desk does not, and no amount of post-processing recovers the detail.
If you are photographing rather than scanning, a few habits change the result more than any software setting.
Some confusions are inherent to the shapes, not failures of the engine. The digit 0 against capital O, 1 against lowercase l against capital I, 5 against S, 8 against B, and 2 against Z are the classic pairs. In running prose the language model resolves these from context. In serial numbers, licence keys, vehicle registrations and account references there is no context, so error rates on those strings are far higher than the overall page accuracy suggests. Always proofread extracted reference numbers character by character.
Recognition returns text, and text is linear. A two-column newsletter may come back with the columns interleaved if segmentation misreads the gutter. Tables lose their cell structure and arrive as rows of words with the alignment gone. Footnotes land wherever they sat on the page rather than at the end of the passage. Headers and page numbers appear inline. None of this is a fault to be fixed by settings; it is a consequence of converting a two-dimensional layout into a one-dimensional stream. For anything structurally complex, expect to spend time reassembling.
Handwriting is a different problem requiring different models, and cursive in particular is unreliable. Text embedded in low-resolution screenshots of user interfaces often falls below the pixel threshold. Heavily stylised logos and marketing typography defeat character models by design. Text rendered over a busy photographic background may not survive binarisation at all. And a scanned page that is already illegible to you will be illegible to the engine — recognition reads what is there, it does not reconstruct what is missing.
The recognition engine is compiled to WebAssembly and runs inside the page. Your image is decoded, processed and read on your own machine, and the extracted text never leaves it. You can confirm this: open developer tools, watch the Network panel, and you will see the engine and its language data load once and then nothing further. Disconnect from the internet after that initial load and recognition still works.
That property is the whole point for the documents people most often need to digitise — passports and identity cards, bank statements, medical letters, signed agreements, invoices and payslips. Those are exactly the pages that should not be sitting on an unknown server.
Almost always an input problem rather than an engine problem. Characters need to be at least twenty pixels tall, the page should be sharp, evenly lit and close to square-on, and the text should have strong contrast against a plain background.
Not reliably. Handwriting recognition uses different models from printed-text recognition, and cursive in particular varies too much between writers. Neat block capitals sometimes work; ordinary handwriting generally does not.
Recognition produces a linear stream of text, so cell boundaries and column alignment are lost. Multi-column layouts can also interleave if the gutter is misread during segmentation.
Zero with capital O, the digit one with lowercase L and capital I, five with S, and eight with B. In ordinary sentences the language model fixes these from context, but in serial numbers and reference codes there is no context, so proofread those carefully.
Around 300 DPI for normal document text. Going higher rarely improves accuracy and makes processing slower; going much lower is the most common cause of poor results.
It depends on which language data is loaded. Each language needs its own trained model, and scripts with connected forms or complex diacritics are generally harder than Latin script.
No. The recognition engine runs inside your browser as WebAssembly. After the engine loads, you can disconnect from the internet and it will still work, which demonstrates that no image is being sent anywhere.
It reads images, so a scanned PDF page needs to be exported or rendered as an image first. A PDF that already contains real text does not need recognition at all, since the text can be copied directly.