Copying text out of a PDF sounds trivial — until the file is a 200-page report, a scanned contract, or a two-column paper that pastes as word salad. The difference between those outcomes is one thing: whether the file contains real text. Here's how to tell, and how to get clean text either way.
A PDF built by Word, LaTeX, or a browser's print dialog stores its words as text objects — strings with positions and font sizes. Those extract perfectly. A scan stores a photograph of the page; the words you can read are pixels, and no amount of selecting will copy them. A third kind, common in legal and medical files, is a scan with an invisible OCR text layer underneath: extraction works, but quality depends on how well that OCR guessed years ago.
The one-second test: open the file, click anywhere on a paragraph, and try to select a word. Selectable means a text layer exists; a blue box around nothing means image-only.
It walks the text objects in the file and rebuilds structure that PDFs don't store directly. A page gives the extractor a pile of fragments with x/y coordinates; the extractor joins fragments sharing a baseline into lines, orders lines top to bottom, and uses the document's own spacing to decide where paragraphs break — a vertical gap noticeably larger than the typical line spacing means a new paragraph. Two refinements matter in practice:
## instead of losing it into a wall of body text.| Your file | Right tool | What you get |
|---|---|---|
| Exported from Word / LaTeX / browser print | Text extraction | Exact characters, instant |
| Scan with OCR text layer | Text extraction | The OCR's best guess, usually fine |
| Plain scan or photo PDF | OCR first, then extraction | Machine-recognized text; check names and numbers |
| Password-protected | Unlock, then either | Nothing works while encrypted |
Rule of thumb: extraction is exact but only works on real text; OCR works on anything visual but is a guess. If the document already has text, never OCR it — you'd be trading perfect characters for a machine's approximations.
Good extractors take a page spec: all, odd, even for split scans, single pages, or ranges like 1-3, 5. This matters more than it sounds. A 180-page regulatory filing where you need section 4 is a ten-second job with a range and a slog without one — and extracting less also means reviewing less, which is the part that actually takes time.
Layout. A PDF doesn't store "this is a two-column article with a sidebar" — it stores positioned strings — so columns can interleave, tables collapse into run-on lines, and footnotes land mid-paragraph. Extraction reliably gives you reading order, paragraphs, and headings; it does not give you a document model. If you need structure rather than text — tables as tables — a full converter or a copy-paste by hand into a spreadsheet is the honest path.
Open your file in the PDF to Text converter: it reads the text layer locally in your browser, takes page specs, rejoins hyphens, and exports plain text or Markdown with headings detected from font sizes. For the surrounding workflow, Organize PDF fixes page order before you extract, and Compare PDFs diffs two versions textually — handy once the text is out. Scans that need OCR rather than extraction are the exception; run those through an OCR step first, then extract the result.
Pages, hyphen rejoins, Markdown export — all local, all free, nothing uploaded.
Open the converter →Check for a text layer first — selectable words mean extraction will work and OCR is the wrong tool. Extract with page ranges instead of wading through appendices, keep hyphen rejoins on, and expect reading order rather than layout. And if a file refuses to give up any text at all, it's telling you it's a picture: OCR it, then extract.