Copy-Pasting Hindi From a PDF Gives Garbled Text

The PDF is on screen and the Hindi looks flawless. You select a paragraph, copy it, paste it into Word, and get nonsense. Different nonsense depending on the file: sometimes Latin letters, sometimes boxes, sometimes Hindi with the vowel signs scattered into the wrong places, sometimes nothing at all. Four separate causes produce those four outcomes, and the fix for one does nothing for the others.

Why a PDF can look right and copy wrong

This surprises people, so it is worth understanding before trying fixes. A PDF stores two things that most readers assume are one thing.

The first is drawing instructions: put glyph number 47 from this embedded font at this position on the page. That is what you see. It is a set of shapes with coordinates, and it has no idea what letter it represents.

The second is a lookup table called ToUnicode, which maps each glyph number back to the character it stands for. That table is what copying reads.

Nothing forces the two to agree. A PDF generator can embed perfect glyph data and write a broken ToUnicode table, or omit it entirely. The page renders beautifully and the copy comes out as garbage, because the two operations never consulted the same data.

Displaying uses shapes. Copying uses a table that maps shapes back to characters. When only the shapes are right, you get a file that looks perfect and copies badly.

Match your symptom to the cause

Latin letters: the PDF used a legacy font

This is the common one for Indian government documents, court orders, exam notifications, and anything produced in an office running KrutiDev or Chanakya. Extraction worked exactly as it should. It handed you the Latin characters the file contains, because that is what a legacy font stores.

Copy the pasted output and run it through the converter. The Latin resolves into Devanagari and the result is Unicode, which pastes cleanly into anything from that point on.

Two things make this case easier than it looks. The output is stable, so a long document converts in one pass rather than page by page. And because the source characters are intact, the conversion is lossless: nothing was approximated on the way through the PDF.

Nothing pastes: the page is an image

Scanned documents contain a photograph of a page. There is no text in the file, so there is nothing to select. Some readers show a selection rectangle anyway, which makes it look like the copy failed rather than that there was never any text.

The test takes a second: try to select a single word. If the cursor draws a box across the whole page rather than snapping to word boundaries, the page is an image.

Optical character recognition is the only path here. It reads the picture and writes a text layer into the file, after which copying works normally. Accuracy on Devanagari is lower than on Latin, and it drops further on faded photocopies, skewed scans, and older documents. Whatever comes out needs proofreading against the original rather than trusting it outright.

Random symbols: the ToUnicode table is missing

This is the case the opening section described, and it is the most confusing to encounter because the file gives no visible clue. The Hindi renders perfectly. Only when you copy does the problem surface.

It usually comes from PDF generators that embed a font subset with a custom internal encoding and then skip writing the mapping table. Older desktop publishing software and some print-to-PDF drivers do this. The document was never built with copying in mind, and for print output nobody noticed.

Practical options, roughly in order of effort:

1. Open the file in a different PDF reader. Extraction logic differs between them, and one may recover where another gives up.
2. Ask whoever produced the file for the source document. A Word or InDesign original sidesteps the whole problem.
3. Run OCR over the PDF, which ignores the broken table entirely and reads the rendered page as an image. This works even though the file technically contains text.

Option three is worth remembering. OCR is usually framed as the fix for scanned documents, and it works just as well on a text PDF whose extraction is unusable.

Vowel signs in the wrong place

Here the copy produces Devanagari rather than Latin or symbols, so this is close to working, but words come out malformed with matras attached to the wrong consonants.

The cause is an ordering mismatch. Devanagari draws some vowel signs to the left of the consonant they belong to, while Unicode stores them after it. The short i is the clearest example: in कि the sign appears first on the page and is stored second in memory. A PDF lays out glyphs in the order they are drawn, so an extraction tool that reads across the page in visual order captures that sign before its consonant and writes it in the wrong place.

Trying another reader is the quickest fix, since tools differ in whether they reconstruct logical order. If the file is important and no reader gets it right, OCR bypasses the ordering problem by reading the rendered result rather than the stored sequence.

Matra displacement also happens outside PDFs, during ordinary font conversion, where the causes and the fixes are different. That case is covered on the page about matras and ikar landing in the wrong position after conversion.

What to try, in order

1. Paste into a plain text editor first. Word processors apply their own font substitution and can mask what came across.
2. Read the output against the symptom table above and identify which of the four cases you have.
3. If the output is Latin, convert it and stop. That case is solved.
4. Otherwise open the file in a second reader and paste again.
5. If nothing improves, ask for the source document.
6. If the source is gone, run OCR and proofread the result.

Edge cases

Part of the document copies fine and part does not

Assembled PDFs often carry sections from different sources, each with its own fonts and its own mapping tables. Handle each section on its own terms rather than looking for one fix that covers the file.

The copy works but line breaks land mid-sentence

PDFs store lines as separate drawing operations with no concept of a paragraph. Extraction preserves the visual line breaks. That is a formatting cleanup rather than an encoding problem, and the text itself is fine.

You need the whole document, not a paragraph

Converting a long legacy-font PDF works the same way as a short one, and the workflow for handling a full document without retyping is covered on the page about converting a KrutiDev Word file to Unicode.

Numbers and punctuation survive but Hindi does not

Digits and Latin punctuation sit in a range most fonts encode identically, so they pass through even when the mapping table is broken for everything else. This is a useful signal that the ToUnicode table exists but is incomplete rather than absent.

PDF extraction is one of several ways Hindi arrives broken. The Hindi font resources index lists the others alongside the fix for each.