Sooner or later someone hands you a PDF and asks you to "just pull the text out". Maybe it's a vendor contract you need to diff, a stack of scanned forms you want to search, or an old Urdu notice someone needs retyped. Whether this takes two seconds or an afternoon depends on one question: does the PDF actually contain text?
This post walks through how to answer that question, which approach to use for each case, and the small habits that make OCR output far less painful to clean up.
Step 1: Find out what kind of PDF you have
PDFs come in two broad flavours:
- Text PDFs are exported from Word, Google Docs, LaTeX, a reporting tool, and so on. The characters are stored as real text with fonts attached.
- Image PDFs come out of scanners and phone scanner apps. Every page is basically a picture. There's nothing to extract until something reads the picture.
The lazy check is to open the file and Ctrl+F for a word you can see. If search finds it, there's a text layer.
If you're on the command line, poppler-utils gives you a more reliable signal:
# Lists the fonts embedded in the PDF.
# An empty table usually means the pages are images (a scan).
pdffonts document.pdf
# Try a direct extraction and see if anything meaningful comes out.
pdftotext -layout document.pdf - | head -40
Watch out for mixed files. A scanned contract with a typed cover page will show fonts, but only page 1 has text. If you're processing a batch, check per page instead of per file (pdftotext -f 3 -l 3 extracts just page 3).
Step 2: For text PDFs, skip OCR entirely
If the text layer exists, use it. Running OCR on a perfectly good text PDF is slower and less accurate than reading the characters that are already there.
A few things to expect:
- Line breaks are visual, not semantic. PDFs store positioned lines, so a paragraph often comes out as several hard-wrapped lines. Most extractors try to rejoin them, but you'll still see odd breaks around hyphens and headings.
-
Multi-column layouts can interleave. Two columns may come out mixed line-by-line.
pdftotext -layoutkeeps the columns side by side, which is often easier to fix by hand. - Tables flatten. Plain-text extraction drops cell borders, so a table turns into rows of words separated by spaces.
If you just need the wording in a usable format, a plain .txt (UTF-8) is the most portable target. If someone non-technical has to edit it afterwards, a .docx is friendlier. For a quick conversion without installing anything, I've used the PDF to TXT tool for plain UTF-8 output and the PDF to Word converter when the result needs to land in Word or Google Docs. Both extract text only, so layout, tables and images aren't recreated. That's the honest trade-off with any text-extraction approach.
Step 3: For scans, OCR is the only way in
Once you've confirmed the pages are images, you need optical character recognition. Tesseract is the usual open-source engine, and the CLI workflow looks like this:
# Render pages to images at 300 DPI
pdftoppm -r 300 -png scan.pdf page
# OCR each page (eng, hin and urd are Tesseract's codes
# for English, Hindi and Urdu; install the language data first)
for f in page-*.png; do
tesseract "$f" "${f%.png}" -l urd
done
Two settings matter more than anything else here.
Resolution
Low-resolution renders destroy small text. Around 300 DPI is the commonly recommended target for printed text. Below that, thin strokes and dots start to merge, and accuracy drops off quickly. Complex scripts suffer the most. Urdu in Nastaliq has diacritic dots and joined letter shapes that just disappear at low DPI.
Language
OCR engines don't read "all writing" at once. They load a model for one script and language. Run English OCR on a Hindi page and you get a scatter of Latin characters, because the engine is hunting for letters that aren't there. Switch to hin and the same page becomes readable Devanagari.
If a page mixes scripts, for example English headings over Hindi body text, pick the language that covers most of the text. Tesseract can also take combined languages (-l hin+eng), but expect it to be slower.
Urdu has one more catch: it's written right to left. If you paste OCR output into an editor that assumes left-to-right, punctuation and numbers can look scrambled even when the recognition itself was fine. Check the paragraph direction before blaming the OCR.
Step 4: Improve the input, not the engine
Most "bad OCR" is really a bad scan. Before you tweak engine settings, fix the source:
- Flatten and straighten the page. Skewed lines and curled book pages break line detection.
- Use even lighting for phone scans. Shadows across the page and glare on glossy paper hide characters.
- Avoid copies of copies. Every photocopy generation loses contrast, so scan the original if you have it.
- Crop out the clutter. Fingers, desk edges and dark borders add noise the engine tries to read.
- Test a few pages first. On a long document, OCR two or three representative pages, check the quality, then run the rest.
Step 5: Proofread the parts that matter
Even on a clean scan, OCR confuses similar shapes: 0 and O, 1 and l, rn and m. Before you trust the output, spend your proofreading time where mistakes are costly:
- Names, amounts, dates and ID numbers
- Headlines and anything set in a decorative font
- Handwriting, which general-purpose OCR doesn't recognise reliably
If you're piping OCR output into code, validate the fields you care about (dates parse, totals add up, IDs match their expected format) rather than assuming the text is correct.
Quick decision checklist
-
pdffontsshows fonts andpdftotextreturns real words? → Extract directly, no OCR. - Empty font table, or garbage text? → It's a scan. Render at around 300 DPI and OCR it.
- Non-English text? → Set the OCR language explicitly (
eng,hin,urd). - Output looks scrambled in Urdu? → Check right-to-left paragraph direction first.
- Huge file? → Test a few pages before running the full batch.
Closing note
I put this together while working on document tools at PKD Ventures, a Kanpur-based company that builds websites, business apps and custom software. We also keep a set of free tools for everyday file jobs like these at pkdventures.in. If your team handles a steady stream of scanned forms or invoices, it's usually worth going beyond one-off conversion to proper field extraction and validation. Either way, getting Step 1 right will save you the most time.
