How to Extract Text From a Scanned PDF or Image (Free OCR, No Sign-Up)

Somewhere between "I have this text" and "I can actually use this text" sits a surprisingly common gap: a photo of a whiteboard after a meeting, a scanned government form, a screenshot of a paragraph you'd like to quote, an old printed page you want searchable — all genuinely contain text, but none of it is selectable, copyable, or editable, because as far as a computer is concerned it's just pixels arranged to look like letters. Optical character recognition (OCR) is the specific technology that closes that gap, and a free, in-browser OCR tool can do it in seconds without installing anything or sending your image anywhere.

What OCR actually does

OCR works by analysing the shapes in an image and matching them against a trained model of what printed characters look like — recognising that a particular cluster of pixels forms the letter "a" the same way a person recognises it by shape rather than by reading pixel values directly. Our OCR Text Extractor uses Tesseract, a widely used open-source OCR engine, running entirely inside your browser via WebAssembly — the recognition model and the actual computation both happen on your device, not on a remote server. This is fundamentally pattern recognition trained on printed text specifically, which matters for what it can and can't do well, covered further down.

Step-by-step: extract text with OCR Text Extractor

1. Open the OCR Text Extractor tool and upload an image (JPG, PNG, WebP) or a PDF.
2. If you uploaded a PDF, use the page arrows to browse to the specific page you need text from — each page is rendered as an image before OCR runs on it.
3. Choose the language: English, Hindi, or both together if the document mixes the two.
4. Click "Extract text" — the first time you use it, your browser downloads a small language model (a few megabytes, cached afterward so it's instant on future uses).
5. Review the extracted text in the editable box, correcting any misreads directly, then copy it or download it as a .txt file.

Getting good OCR accuracy — what actually matters

OCR accuracy is overwhelmingly a function of image quality going in, more than anything about the engine itself. Resolution matters — text that's too small or blurry in the source image simply doesn't have enough pixel detail for the model to distinguish similar-looking characters reliably. Lighting and contrast matter just as much: an evenly lit page with dark text on a light background gives a far cleaner result than a photo with glare, shadows, or low contrast between text and background. Keeping the page reasonably straight (not heavily skewed or at an angle) also helps meaningfully, since heavy skew distorts character shapes in ways that can confuse the recognition model even when the text itself is perfectly legible to a human eye. If a first attempt comes back with a lot of errors, retaking the photo with better lighting and a straighter angle is usually a more effective fix than anything else.

English, Hindi, or both — picking the right language mode

Bilingual documents — a government form with both English and Hindi labels, a notice printed in both languages side by side — are common enough in India that language choice deserves a specific mention. Running OCR in "English + Hindi" mode lets the engine recognise both scripts in a single pass, which is the right choice for a genuinely mixed document. But running a single-language mode when the document is actually only in one language tends to give a slightly more accurate result than the combined mode, since the model has fewer possible characters to choose between for each shape — so if you know a document is purely English or purely Hindi, picking that specific language rather than defaulting to both can improve accuracy on borderline or lower-quality images.

Scanned PDFs vs photographed pages

The tool handles both, but the workflow differs slightly. For a PDF, each page is rendered as an image before OCR runs on it, and the page navigator lets you jump to the exact page you need rather than being limited to the first one — useful for a multi-page scanned document where only one or two pages actually contain the text you need. For a photographed page (a phone photo of a printed document, a whiteboard, a book page), quality tends to vary more than a proper scan, since lighting, angle and camera shake are all in play in a way they aren't for a flatbed scan — which is exactly why the image-quality factors above matter more for photographed pages than for a clean digital scan.

Common use cases for OCR

• Digitising old printed notes or documents into text you can search, edit and store properly instead of as a static image.
• Pulling a quote or passage out of a screenshot without retyping it by hand.
• Converting a scanned government certificate or form into editable, searchable text for your own records.
• Extracting line items or totals from a photographed invoice or receipt for expense tracking.
• Getting text off a scanned book or magazine page for reference or quotation.

What OCR genuinely can't do well

It's worth being upfront about the limits here rather than overselling what OCR does. This is a printed-text recognition model — cursive or handwritten text is a fundamentally different, much harder recognition problem, and results on handwriting will generally be unreliable to unusable, not just slightly less accurate. Very low-resolution or heavily blurred images will produce a genuinely poor result no matter what settings are chosen, since the underlying detail simply isn't in the source image to begin with. Dense tables and multi-column layouts are also a weak spot — OCR extracts text in roughly the reading order it detects, which can flatten a table's row/column structure into a jumbled sequence rather than preserving it, so a table-heavy document may need manual reformatting after extraction rather than expecting the structure to survive automatically. And highly stylised, decorative, or unusual fonts — the kind not well represented in the model's training data — will also produce a lower-accuracy result than a standard printed typeface.

Privacy — does your image get uploaded?

No — the actual recognition runs entirely in your browser using WebAssembly, and your image or document is never sent to a server at any point. The one thing that does involve the network is a one-time download of the language model itself (a general-purpose recognition model, a few megabytes, cached in your browser after the first use) — that's downloading a generic tool, not uploading your personal content, and it only happens once per language per device.

When OCR is faster than just retyping it yourself

For a single short sentence or a phone number, typing it out by hand is often genuinely faster than uploading an image and reviewing the OCR result for errors — OCR earns its keep on volume and length, not on a two-word caption. A full page of dense paragraph text, a multi-paragraph scanned letter, or a long list of line items is exactly where OCR pulls ahead, since retyping that manually costs minutes while extracting and proofreading an OCR result costs seconds to a minute depending on image quality. A reasonable rule of thumb: if what you need is more than a line or two of text, OCR is almost certainly the faster path; for something trivially short, it may not be worth the round trip.

Preparing an image before you upload it

A little care before uploading does more for the result than anything inside the tool itself. Framing the shot so the text fills as much of the image as reasonably possible — rather than a small block of text surrounded by a lot of empty background — gives the model more usable pixel detail per character. Avoiding a shadow cast across part of the page (common with a phone held at an angle under a single overhead light) prevents a genuinely legible section of text from reading as inconsistent contrast to the model. And if a proper flatbed or app-based scanner is available instead of a handheld phone photo, it's worth using it — a scanner's even lighting and fixed, straight angle consistently outperforms a handheld photo for OCR accuracy, even when the photo looks perfectly readable to a human eye.

One file at a time — and why that's fine for most real use

This tool processes one image or one PDF page at a time rather than batch-processing a folder of files in one pass, which is a genuine constraint worth knowing upfront rather than discovering partway through a task. For a single scanned form, a screenshot, or working through a multi-page PDF one page at a time via the page navigator, this is no real limitation. For someone who genuinely needs to run OCR across dozens or hundreds of separate image files in one operation, a dedicated batch-OCR pipeline would be a better fit than a single-file browser tool — but that's a meaningfully different use case from extracting text out of an individual document or photo, which is what the large majority of real OCR needs actually look like.

OCR as an accessibility tool

Beyond the obvious "turn an image into text I can copy" use case, OCR has a genuinely important accessibility application: converting an image-only PDF or a photographed document into real text is often the only way a screen reader can access that content at all, since a screen reader has nothing to read from a flat image no matter how legible it looks visually. Extracting the text separately and pairing it with the original document — or simply sharing the extracted text alongside a scan — is a small, concrete step that makes previously image-locked content usable for someone relying on assistive technology, and it's worth keeping in mind as a reason to run OCR even on a document you can already read perfectly well yourself.

OCR text vs a searchable PDF — a distinction worth knowing

It's worth being clear about exactly what this tool produces: plain, copyable text extracted from an image, ready to paste, edit or save as a .txt file. That's a different output from a "searchable PDF" — a PDF where the original scanned image stays visible on the page, but an invisible layer of recognised text sits underneath it so the file becomes searchable and selectable while still looking exactly like the original scan. If what you actually need is a searchable PDF specifically (rather than the text itself, pulled out separately), that's a different tool and workflow — this one is built for getting the text itself out, not for reconstructing the original document with a hidden text layer.

Common mistakes

• Trusting extracted numbers or dates without a quick visual check against the source image — misread digits are the most consequential kind of OCR error.
• Using a low-resolution or poorly lit photo when a better one was easy to retake — image quality drives accuracy more than any setting in the tool.
• Running "English + Hindi" mode on a document that's actually purely one language, when picking the single correct language would have given a cleaner result.
• Expecting a table's row/column structure to survive extraction automatically, rather than expecting to reformat it manually afterward.
• Assuming OCR will read handwriting reasonably well — it's trained on printed text, and handwritten or cursive input is a different, much less reliable case.

The short version: OCR turns printed text trapped in an image or scanned PDF back into real, editable, copyable text, running entirely in your browser with nothing uploaded except a one-time generic language model. Good lighting, reasonable resolution, and a straight page do more for accuracy than any setting — pick the correct language (or both, for genuinely bilingual documents), and always give extracted numbers and dates a quick visual check before trusting them fully.