Retyping a scanned contract, a screenshot of a table, or a photo of an invoice wastes time you don't have. OCR (optical character recognition) reads the characters in an image and turns them into editable text — and you no longer need desktop software or a paid subscription to do it.
This guide covers how to convert a JPG to text, turn a scanned PDF into an Excel sheet, pull numbers out of an invoice photo, and even read messy handwriting — all for free, directly in your browser.
Depending on what you plan to do with the extracted text, you can export it in the format that fits: a Word document for editing paragraphs, an Excel sheet for tables and invoices, a PowerPoint slide for presentations, or plain text for quick copy-paste.
Best for letters, contracts and paragraphs of text.
Ideal for invoices, tables and scanned spreadsheets.
Turn a photographed slide or poster into PowerPoint.
Quick copy-paste output for notes or emails.
Runs fully in your browser with WebAssembly — no upload limit, no sign-up.
Extract My Text →Invoices are usually tables of line items, quantities and totals — exactly the kind of layout OCR handles well when you export to Excel instead of plain text. Photograph or scan the invoice, run it through the converter, choose Excel as the output, and you get an editable spreadsheet you can correct, total, or import into accounting software.
Handwritten notes are harder for any OCR engine than printed text, but reasonably neat handwriting — especially block capitals or clear cursive — is often readable. Results vary with handwriting style, so it's worth reviewing and correcting the extracted text in the editable preview before you rely on it.
No. The OCR engine runs locally using WebAssembly, so your image never leaves your device. This also means there's no upload limit and no queue — the conversion starts the moment you click Run OCR.
OCR runs through recognisable stages. The image is cleaned up and converted toward black and white, which is called binarisation. Skew is corrected so lines run horizontally. The page is segmented into blocks, then lines, then individual character shapes. Each shape is classified against a model of what letters look like. Finally a language model reviews the result, because context resolves ambiguity that shape alone cannot — "rn" versus "m", "0" versus "O", "1" versus "l" versus "I".
Every one of those stages can fail, and they fail in ways that are usually predictable from the input. Almost all real-world accuracy problems trace back to the image rather than the recogniser.
| Factor | Good | Problematic |
|---|---|---|
| Resolution | 300 DPI; capital letters ~20+ px tall | Small text in a wide phone photo |
| Contrast | Dark text, light background | Grey on grey, photo backgrounds |
| Focus | Sharp throughout | Motion blur, shallow depth of field |
| Angle | Flat and square to the page | Perspective from an angled phone |
| Lighting | Even | Shadow of your own hand or phone |
| Typeface | Clean serif or sans | Script, decorative, heavy italics |
Plain text is right when you want the words and nothing else — for search, re-use or feeding another program. A Word document suits prose you intend to edit. A spreadsheet suits genuinely tabular data, though be prepared to repair the grid. A searchable PDF, where an invisible text layer sits over the original page image, is the best choice for archiving: it looks exactly like the original and can still be searched, and recognition errors do not corrupt the visible document.
OCR errors are quiet. A misread digit in an invoice, a decimal that shifted column, or a transposed figure in a statement will not announce itself, and the resulting document looks entirely plausible. For anything financial, medical or legal, treat recognised output as a draft that requires checking against the original — particularly every number. Recognition accuracy on clean printed text is high, but "high" is not "perfect", and the errors land precisely where they matter most.
The documents people run through OCR are rarely trivial: identity papers, payslips, bank statements, medical letters, contracts, school records. Uploading those to a free online recogniser means handing a complete copy to a company whose retention policy you have not read and whose staff access you cannot see.
Recognition on this site runs entirely in your browser. The image is processed locally and nothing is transmitted or stored. You can confirm it rather than trust it — open developer tools, watch the Network tab while recognising, and see that no request carries your image. Or load the page, disconnect from the internet, and run it anyway.
Browser-based recognition is slower than a dedicated desktop engine and works within a tab's memory, so very large multi-page documents are better processed in batches. Language support depends on the models available, and unusual scripts or heavily stylised type will be weaker than clean printed Latin text. None of that changes the fundamental point: for the great majority of everyday documents, a well-taken photograph produces a result that needs a quick proofread rather than a retype.
Almost always the image rather than the recogniser. Low resolution, poor contrast, motion blur, an angled shot or shadow across the page all break the early stages. Photograph the page flat, in even light, from directly above and filling the frame, and accuracy usually jumps dramatically.
Around 300 DPI, or close enough that capital letters are at least twenty pixels tall. Going much higher rarely helps and slows processing; going lower is the single most common cause of poor recognition.
Generally not well. Handwriting recognition is a fundamentally different problem from printed text, and general-purpose OCR engines are built for print. Neat block capitals sometimes work; ordinary cursive usually does not.
Because digits have no linguistic context for the language model to correct against. Words benefit from surrounding words, but 0 and O, 1 and l, 5 and S, 8 and B look alike and stand alone. Always verify figures against the original.
Plain text for reuse and search, Word for prose you intend to edit, a spreadsheet for genuinely tabular data, and a searchable PDF for archiving - the last keeps the original page image with an invisible text layer over it, so errors never corrupt what you see.
Column structure is inferred from where text sits on the page, so centred or ragged columns scramble. Extract that section as plain text instead and use your spreadsheet's Text to Columns feature, which is usually faster than repairing a broken grid.
No. Recognition runs entirely in your browser and the image never leaves your device. Watch the Network tab in developer tools while processing, or disconnect from the internet after the page loads - it still works.