Toolminex
PDF & Documents

PDF OCR vs Text Extraction: Which One Your PDF Actually Needs

ToolminexUpdated 2026-10-307 min read

Two PDFs can look identical on screen while being completely different inside. One contains real text that software can read directly. The other is a photograph of a page, and to a computer it's just pixels. That difference decides whether you need text extraction or OCR, and picking the wrong one is why people end up with empty output, garbled characters, or hours of retyping. This guide explains what's inside each kind of PDF, how to tell them apart in seconds, and what each method can and can't do.

Two kinds of PDF

A born-digital PDF is made by software: exporting from Word or Google Docs, "printing" to PDF, or generating an invoice from an accounting app. The file contains text objects. Each one says, in effect, "draw these characters, in this font, at this position". The characters are already there as data.

A scanned PDF is made by a scanner or a phone camera app. Each page is an image. There may be no text objects at all. What looks like a paragraph is a grid of coloured pixels, and getting words out of it means recognising the shapes of letters. That's what OCR (optical character recognition) does.

There's also a hybrid: a scanned PDF that's already been through OCR, with an invisible text layer placed behind the image. Many scanner apps and office copiers produce these. They look like scans but behave like born-digital files when you search or copy.

The ten-second test

  1. Open the PDF in any viewer and try to select a sentence with your cursor.
  2. If individual words highlight, there's a text layer. Use text extraction.
  3. If the cursor draws a box over the whole page, or nothing selects, it's an image. Use OCR.
  4. As a second check, press Ctrl+F (Cmd+F on a Mac) and search for a word you can see. If the viewer can't find it, there's no usable text layer.

How text extraction works

Text extraction reads the text objects straight out of the file. Nothing is being guessed, so when the PDF is well made, the output is character-perfect: every digit in an invoice total, every letter in a name. It's also fast. A 100-page report takes seconds.

The hard part isn't reading characters. It's putting them back in the right order. A PDF stores text as positioned fragments, not as paragraphs. The file doesn't necessarily know that one line follows another, or that a page has two columns. Common problems that come from this:

  • Columns get interleaved. In a two-column layout, the extractor may read across both columns line by line, mixing the end of one sentence with the start of another.
  • Tables flatten. Cell values come out as a stream of words with the row and column structure lost.
  • Some fonts store "fi" or "fl" as a single glyph, and some PDFs map glyphs to the wrong characters. You get "finance" or random symbols even though the page looks fine.
  • Words split across lines may come out as "pay- ment".
  • Headers, footers and page numbers get mixed into the body text.

The PDF to Text tool uses Mozilla's PDF.js library to read the text layer of every page in your browser. It joins the fragments on each page with spaces and separates pages with blank lines. That keeps the words and their order within the file, but not line breaks or layout, so plan to tidy up structure by hand for tables and multi-column documents.

How OCR works

OCR starts by rendering the page as an image, then runs a recognition model over it to predict which characters the shapes represent. Modern OCR uses neural networks rather than old-style template matching, and it's very good on clean printed text. But it's always a prediction. Similar-looking characters get confused: 0 and O, 1 and l and I, 5 and S, rn and m. In a paragraph of prose, a human reader skims past these. In an account number or a total, one wrong character makes the value wrong.

Resolution matters a lot. OCR needs enough pixels per character to tell letters apart. Here's how an A4 page and 10-point text work out at common scan resolutions:

1 point = 1/72 inch, so 10 pt text is 10/72 inch tall. Pixels = inches × DPI. A4 = 8.27 × 11.69 inches.
ResolutionA4 page in pixelsMegapixelsHeight of 10 pt text
144 DPI1190 × 16842.020 px
150 DPI1240 × 17542.221 px
200 DPI1654 × 23383.928 px
300 DPI2481 × 35078.742 px

300 DPI is the common recommendation for scanning documents you intend to OCR, and the arithmetic shows why: 10-point text gets about 42 pixels of height, so even small details like the dot on an i are several pixels across. At 150 DPI, the same text gets about 21 pixels, which is usually still readable for clean print but leaves little margin for small fonts, footnotes or a blurry phone photo.

Using the Toolminex PDF OCR tool

The PDF OCR tool renders one page of your PDF at twice the PDF's base size, which works out to 144 DPI (the first row of the table). It then runs a small transformer-based OCR model trained on printed text, in your browser. The model downloads the first time you use it and is cached afterwards. Your PDF isn't uploaded.

  1. Do the selection test first. If text selects, use PDF to Text instead; it's faster and exact.
  2. Load the PDF in the OCR tool and choose the page number.
  3. Wait for the model on the first run, then run OCR.
  4. Check every number, name and code in the output against the page preview before you rely on it.

Choosing the right method

SituationUseWhy
Exported report, e-statement, invoiceText extractionThe text is already there and exact
Scanned contract or letterOCRThere's no text layer to extract
Scan that already searches with Ctrl+FText extractionSomeone already ran OCR; reuse it
Born-digital file that extracts as gibberishOCRThe font encoding is broken, but the rendered page looks right
Handwritten notesNeither tool hereThe OCR model is trained on printed text

The fourth row is worth remembering. Some PDFs have a text layer with broken character mapping, so extraction returns nonsense even though the page displays perfectly. OCR ignores the text layer and reads what's drawn, so it can rescue those files.

Limitations

  • OCR here is one page at a time. There's no batch mode across a whole document. For a 40-page scan, a desktop OCR application will be quicker.
  • The OCR model works best on short runs of printed text. It was trained to read lines of printed text. On dense full pages, multi-column layouts or small print, the output can be incomplete or merge lines. Cropping or splitting a page into clearer sections before OCR can help.
  • Handwriting isn't supported well. The model was trained on printed text, so handwritten notes will produce poor results.
  • Text extraction loses layout. Line breaks, columns and table structure aren't preserved; you get the words in reading order as the PDF stores them.
  • Neither tool keeps formatting. Bold, headings, fonts and images don't come through. If you need an editable document with layout, these are the wrong tools.
  • Files that need a password to open can't be read until you remove the protection with the password.
  • Always proofread OCR output. No OCR system is perfect, and errors cluster exactly where they hurt most: numbers, codes and names.

If you have the choice, get the born-digital version of a document rather than a scan. Ask for the emailed statement instead of the printed one, or the exported PDF instead of a photo of the screen. Exact text beats the best OCR every time.

Get the text out of your PDF

Try text extraction first. If nothing comes out, the page is an image and OCR is the next step.