OCR Explained (English + Hindi)

The first time I ran OCR on a scanned contract, I was amazed. The tool pulled out every word in about twenty seconds. Then I scrolled to the signature block and found that the tool had cheerfully converted a paragraph of handwritten notes into "8 - . 4 amass. See 34--". Not so amazing.

OCR is a genuinely useful technology that comes with genuinely sharp limits. This guide explains what it is, what it does well, what it fails at, and how to get the best results — especially for Hindi and English documents.

What OCR actually does

OCR stands for Optical Character Recognition. Its job is to turn pictures of text into actual text — characters that a computer can search, copy, and process.

An image file has no notion of "words". It's just pixels. OCR is the process of looking at those pixels, finding patterns that look like letters, and outputting the character codes those letters represent.

For a printed A4 page at 300 DPI, modern OCR engines achieve accuracy in the 97-99% range. That sounds great until you realise 99% accuracy means roughly one wrong character every hundred. On a 5000-character page, that's 50 errors. For a legal contract, 50 errors is a disaster.

The four stages of OCR

1. Image preprocessing

The engine first normalises the image. It detects the text angle and rotates it straight, converts to greyscale, then to a binary black/white threshold, and removes noise.

This stage is where most OCR problems originate. A skewed scan, an overexposed photo, or a low-contrast document confuses every downstream stage. Fix the image before OCR, and everything improves.

2. Layout analysis

The engine identifies regions of the image: text paragraphs, headings, tables, images, margins. It has to guess where one column ends and another begins, and in what order to read them.

Layout is where multi-column documents often break. A newspaper-style two-column page can get read straight across, mixing up sentences. Tables confuse the engine into reading cell contents in the wrong order.

3. Character recognition

For each detected text region, the engine slices the image into character-sized chunks and classifies each one. Modern engines use neural networks trained on millions of examples.

Character recognition works brilliantly on clean printed text in Latin scripts. It works much worse on Devanagari's conjunct characters (where multiple letters combine into one glyph) and on cursive handwriting.

4. Post-processing with a language model

Finally, the engine runs the raw output through a language model to fix obvious errors. If it sees "teh" and knows English, it corrects to "the". If it sees "app1e" it guesses "apple".

For English, this is a big help. For Hindi, less so — the language models are smaller and the concatenation rules are different. For technical text with jargon, chemical formulas, or code, post-processing can make things worse by over-correcting.

When it works brilliantly

• Printed documents at 300 DPI. Clean scans of book pages, contracts, reports — this is OCR's sweet spot.
• Simple single-column layouts. Standard paragraphs, headings, and lists are handled well.
• Common English vocabulary. News articles, textbooks, business documents.
• Machine-printed forms. Text fields filled by a printer, not a pen.

If your document fits these criteria, expect 98-99% accuracy. That means a few errors per page, usually obvious ones that context can resolve. Not perfect, but genuinely useful for search and rough extraction.

When it fails

• Handwriting. This is the biggest disappointment. Tesseract — the engine we use — was not trained on handwriting. Cursive produces garbage. Even block handwriting produces many errors.
• Low resolution. Below 150 DPI, characters blur together. Errors rise to 10-30%.
• Complex layouts. Newspapers, magazines, brochures with text wrapping around images — the engine can't reliably determine reading order.
• Tables. Cell contents often get misread or merged. There's no standard way to represent a table in plain text output, so results vary wildly.
• Unusual fonts. Decorative fonts, script fonts, and very small type (<8pt) confuse the character classifier.
• Multi-language documents. A page with Hindi and English text is harder than either alone — the engine has to guess script and can pick wrong.
• Chemical formulas and mathematics. Special symbols and layout are outside the training data.

Hindi OCR in practice

Hindi uses the Devanagari script, which is more complex than Latin for OCR in several ways:

• Conjunct characters. Two consonants can combine into a single glyph — क + ष = क्ष. The engine has to recognise these combinations, not individual letters.
• Vowel signs (matras). Vowels appear as marks above, below, before, or after consonants. Their placement relative to the base letter is significant.
• Aspirated consonants. भ vs ब — a small detail distinguishes the two.
• Danda and other punctuation. The sentence-ending "।" needs to be recognised as distinct from other marks.

In our experience with Tesseract's Hindi model:

• Clean, standard printed Hindi at 300 DPI: ~95% accuracy character-wise. Word-level is lower because Devanagari words are harder to correct via dictionary.
• Printed Hindi from low-resolution scans: ~70-80% accuracy. Errors compound.
• Handwritten Hindi: very poor — under 40% accuracy, often unusable.
• Hindi + English mixed: ~80% accuracy, with occasional script confusion (English words getting Devanagari interpretations or vice versa).

So Hindi OCR is genuinely useful for printed material, but the bar for quality is higher than English.

Searchable PDFs: how they work

A common OCR task is: turn a scanned PDF (which is really just images of pages) into a searchable PDF. The output looks identical but supports Ctrl+F.

What actually happens under the hood:

1. Each page is rendered to an image at the requested DPI.
2. The OCR engine extracts text and positions for each word — its bounding box on the page.
3. A new PDF is created. The original page image is embedded as the visible content.
4. An invisible text layer is drawn on top of the image, with each word positioned to match where it appears visually.

The result: visually identical to the original scan. But now a PDF reader can find text, and copying text works.

There's an important nuance: the invisible text is often not exactly aligned with the visual text. Tiny offsets of a pixel or two mean copying a passage sometimes picks up characters from adjacent words. It's not perfect.

Our OCR PDF tool produces searchable PDFs in this way. We use a very low opacity white text layer, which most PDF readers index properly. It's documented as an approximation — true invisible rendering mode isn't exposed by the client-side PDF library we use.

FAQ