How to Copy Text from a PDF: Five Reasons It Fails

Every guide gives the same instruction: drag to select, then press Ctrl+C or Cmd+C. If you are reading this you already tried that, and either nothing highlighted, or the paste came back scrambled, or it came back as characters nobody has ever typed.

The instruction is not wrong; it answers a question you no longer have. What breaks sits one level down, in how a PDF stores what it shows you — five separate failures with five separate answers.

What is actually in the file

A PDF page is a list of drawing instructions. One says, in effect: using font F3 at 11 points, at position 148.5, 604.2, show this run of character codes. Nothing above that level is recorded — no sentence, no paragraph, no column, no line, and no order in which a person is meant to read the fragments. Often not even the spaces, since the typesetter can simply advance the pen before drawing the next word.

Copying is therefore a reconstruction. Something collects the fragments, groups them by baseline, measures gaps to find where words end, and judges which block follows which. All of it is inference from geometry, which is why one program copies a file cleanly and another makes a mess of the same file. The exception is a tagged PDF, which does record headings, paragraphs and reading order. Files prepared for accessibility have one; most do not.

Nothing highlights: the page is a picture

Drag across a word and nothing turns blue, or one click throws a selection box around the entire sheet — because the sheet is a single object. That file is a scan, a fax export, or a photo saved to PDF, and not one character is stored in it. No extraction tool can help. The letters have to be guessed out of the pixels, which is optical character recognition, a different machine that makes mistakes an extractor never makes: 1 for l, rn for m.

This site has no OCR tool yet, so the honest advice points elsewhere. Google Drive runs recognition when you open an uploaded PDF with Google Docs, and Acrobat keeps the function under Scan & OCR. Proofread the numbers afterward: recognition is confident even when wrong.

The words arrive in the wrong order

The text pastes, and it is nonsense of a specific kind — grammatical fragments welded into impossible sentences, page numbers landing mid-clause, a footnote cutting through an argument. The document has two columns and was read straight across.

The usual implementation sorts every fragment by vertical position, then horizontal, and joins them up. That is right on a single-column report and wrong the moment there are two, because each sweep across the sheet takes half a sentence from one column and half from the other. Journal articles, annual reports and conference programs all arrive like this.

Reading it correctly means finding the columns first. A vertical channel runs between them that no fragment ever crosses, and once it is located the order follows. The hard part is deciding whether the channel is real: a heading spanning both columns crosses it and appears to close it, and a wide gap may just be a table. What settles it is a vote — a page counts as columnar only when most of its lines are themselves split by a gap that wide.

That is the work pdf-to-text does, and it reports what it found per page so you can overrule it: a two-column form with labels on the left and values on the right should be read straight across, and no geometry can tell that apart from an article.

If the wide gaps form rows and columns you need to calculate with, copying plain text is the wrong destination. PDF to Excel shows the proposed table regions as pictures, lets you correct the recovered cells, and puts each table you choose on a separate workbook sheet. It still needs a text layer; a picture of a table needs OCR first.

The letters come back as gibberish

Two different things produce this. The first is a broken map. Text is stored as character codes, and those codes are not Unicode — they are whatever numbering the producing program assigned when it embedded the font. In a subset font, carrying only the glyphs the document actually used, that numbering is often just the order the glyphs were added.

Display does not care: code to glyph, glyph to ink, and the page looks immaculate. Copying needs the opposite direction, code back to a character, and that exists only if the font carries a ToUnicode table. Without one there is nothing to translate with, and the raw codes land in your clipboard read as though they were text:

on the page:      Chapter One
in the clipboard: Fkdswhu#Rqh

The tell is consistency: the same real letter always arrives as the same wrong one, because a fixed offset is applied to every code. No reader setting fixes it, because the information is absent from the file — the ways out are recognition on the rendered page, which does work, or asking whoever produced the document for the original.

The second cause is a different problem entirely. If the text is mostly fine but every accented character has become a pair of symbols, extraction succeeded and something afterward opened the result assuming the wrong encoding. Fix that where the text file was opened; the PDF is fine.

The document says copying is not allowed

Some files carry permission flags. The PDF security handler stores bits covering printing, modification, and extraction of text and graphics, and a reader that honors them grays out Copy.

Be precise about what that is. Two passwords exist: a user password, required to open the document at all, and an owner password, required to change its permissions. A file that opens without prompting anybody has no user password, so the key is derivable by every reader on earth. The bytes may be encrypted, but the encryption is not what stops you — the flag is, and honoring it is an agreement between conforming readers rather than a lock. A document that refuses to open without a password is the other case, and there the content really is unreadable.

The flag tells you intent, and this page is not going to walk you around it. Where the need is legitimate, asking whoever sent the file works better than people expect — and where the document is yours already, which of the two locks it carries decides whether anything can be done at all. That is a question with its own page: removing a password from a PDF starts by telling the two apart.

The text comes back from under a black bar

This is the one case where copying working is the bad news. Drag across a redacted passage, press copy, and the name you were not supposed to see arrives in the clipboard — because the black bar was a shape drawn on top of the page rather than a deletion of the text beneath it. Both instructions are in the file and both still execute; one of them merely paints over the other on screen.

If you are checking a document somebody sent you, this is the fastest test there is, and a result that arrives means the file is not safe to pass on. If you are the one doing the covering, the shape tools in every ordinary editor produce exactly this, and the fix is an operation that removes the characters rather than hiding them: how to redact a PDF covers the four ways to check a finished file and what else survives a redaction that otherwise went well.

A handful of characters are wrong

Everything pastes and reads correctly, and then a search for file finds nothing on a page that plainly contains the word.

That is a ligature. Professionally set documents store fi, fl, ffi and ffl as one glyph each, and they come back as one character each — visually perfect, and not the letters you searched for. Software with no glyph for them drops them instead, turning office into oce. Three relatives: a word broken across a line carries a real hyphen, so hy- and phenation arrive separately; curly quotes and long dashes replace their straight equivalents and will break a shell command; and a non-breaking space looks exactly like an ordinary one while matching nothing you type.

Extraction can undo two of those — ligatures back to plain letters, hyphenated words rejoined. For the rest, text cleaner shows what is in the string before it changes anything.

What to do, in order

Test one word first. If dragging across a single word highlights nothing, or highlights the whole page, you have a scan and the remaining steps do not apply.

Select all, then paste into a plain text editor. Notepad, TextEdit in plain mode or any code editor shows exactly what arrived. A word processor hides the damage behind its own formatting, which is how people spend twenty minutes repairing something they have not seen. On an iPhone, iPad or Chromebook used without a keyboard, follow the copy-and-paste-without-formatting route instead; it uses a plain browser field when the touch menu has no matching command.

Stop hand-repairing after the second paragraph. If the order is wrong, or every line ends in a hard return, manual work does not scale past a page. Send the file through pdf-to-text instead: it rebuilds the order, joins wrapped lines back into paragraphs, and names any page carrying no text before you download anything. When what you actually want is to read the thing on a phone rather than copy a passage out of it, pdf to epub is the better destination — it removes the running heads and page numbers that make a converted book unreadable, and lets the text reflow to the screen.

Preview on a Mac, and Edge’s built-in viewer or Acrobat Reader on Windows, all select text perfectly well — and none of them reorders columns. On a phone, a long press that produces no selection is the same picture-of-a-page verdict, reached in one gesture.

How to copy text from a PDF