When you copy text from a PDF and it pastes as symbols, boxes or the wrong letters, the page is fine and the map behind it is not. A PDF paints text with character codes, and a separate table in each font, the ToUnicode map, tells a viewer which character each code stands for. When that map is missing or wrong, the page still draws, since drawing needs only the shapes, but copy, search and screen readers get codes they cannot translate. The usual causes are fonts subset with private codes, Type 3 fonts, ligatures and right-to-left scripts. You can check which in a minute with pdffonts, and the reliable fixes are a fresh export from the source document or OCR.

Why does a PDF look right but copy wrong?

Because drawing and copying use different parts of the font. Drawing needs only the glyph for each code. Copying needs the character, and the standard lists where to find it, in order. First: “If the font dictionary contains a ToUnicode CMap (see 9.10.3, “ToUnicode CMaps”), use that CMap to convert the character code to Unicode.” Failing that, a standard encoding or standard glyph names. Failing both, the viewer guesses, and the guess is what you paste.

Picture a subset whose producer gave its glyphs codes of its own, so that code 21 (hexadecimal) draws an “é”. In the standard tables, code 21 is “!”. One line of a ToUnicode map says otherwise:

<21><21><00e9>

With that line, the letter copies as “é”. Without it, the page looks the same, but a viewer that falls back on a standard table pastes “!” wherever the letter occurs.

One character code, two paths The code 21 is drawn by the font as e with an acute accent; copying it gives e with an acute accent through the ToUnicode map, or an exclamation mark without the map. code <21> the font draws é ToUnicode map on the page what you paste: with the map: é without it: !
Drawing needs only the font; copying needs the map. Without it, the code is pasted as whatever it means in a standard table.

The demo documents of PDF Textfix show the other side. pdffonts lists every one of their fonts as a TrueType subset with MacRoman encoding and no in the uni column: no ToUnicode map at all. Their text still copies, because MacRoman is a standard encoding, which names the character behind each code they use. In the demo CV, the é of “cafés” is stored as the byte 8E, which is é in Mac Roman, and pdftotext extracts the word as printed. The full walk through codes, fonts and maps is in how a PDF stores text.

Why does copied PDF text paste as weird characters?

A subset with private codes and no ToUnicode map. A producer may renumber the glyphs of a subset with codes of its own, as in the example above. The page draws correctly; the codes mean nothing outside the font. Fonts with two-byte glyph numbers are the extreme case. The standard says of one such font: “In the absence of a ToUnicode entry, no information would be available about what the glyphs mean.” Pastes look like random punctuation, or nothing.

A wrong map. A ToUnicode table can be present and still point glyphs at the wrong characters. The paste is then consistent and consistently wrong: the same letter always comes out as the same wrong one, and the file gives no hint which.

Type 3 fonts. In a Type 3 font, the standard says, “glyphs shall be defined by streams of PDF graphics operators.” The shapes are little drawings. Some carry glyph names or a map that a viewer can use; others carry neither, and their text cannot be copied as characters at all.

Ligatures. “fi”, “fl” and “ffi” are often one glyph. Without a map that expands it, the pair can paste as a single unusual character, or vanish, so that “find” comes out as “nd”.

Right-to-left and joined scripts. Arabic and Hebrew may be stored in painting order, left to right, with contextual shapes, so a paste can come out reversed.

How do you check what is wrong with a PDF’s text?

Two commands from Poppler (brew install poppler) tell you most of it:

pdffonts document.pdf
pdftotext -layout document.pdf - | less

In the pdffonts table, uni says whether a font has an explicit ToUnicode map, type shows Type 3 fonts, and encoding shows Identity-H or a named table. A no is a lead, not a verdict; the man page itself notes that “the absence of a ToUnicode map doesn’t necessarily mean that the text can’t be converted to Unicode”, since a standard encoding can be enough. Every font of the demo documents says MacRoman and no, and they copy perfectly.

Then compare the pdftotext output with the page: if one font’s text is wrong and the rest is right, that font is the cause. On a Mac, Preview gives the same test without a terminal: “Choose Tools > Text Selection, drag over the text, then choose Edit > Copy.” Paste into TextEdit and compare.

How do you fix copied PDF text that pastes as symbols?

Get a fresh export. The source document (Word, Pages, InDesign, LaTeX) still knows its characters. Exported again with a current app and fonts that embed with their Unicode tables, the file usually copies cleanly. If the PDF came from someone else, ask them for it.

OCR the page. Optical character recognition reads the shapes and writes a new, invisible text layer, so copy and search use that instead of the broken map. OCRmyPDF, a free command-line tool, “adds an optical character recognition (OCR) text layer to scanned PDF files, allowing them to be searched”. A PDF that pastes gibberish already has text, though, and by default OCRmyPDF stops on it with “page already has text! – aborting (use –force-ocr to force OCR)”. Its documentation names this case as one the option is for, “fixing OCR text with a damaged character map (text is selectable but not searchable)”:

ocrmypdf --force-ocr in.pdf out.pdf

The option has a cost. Every page is turned into an image with an OCR layer on top, so the real text and vector graphics become pixels, form fields are flattened, and, in the documentation’s words, “the file usually grows and vector content is lost”. Keep the original, and check names and numbers in the result.

Retype the passage. For a paragraph, it is often the fastest fix. Repairing a ToUnicode map by hand means knowing what every glyph is, which is OCR done by eye.

What does broken text mapping mean for editing?

An editor faces the same problem: to change a line, it has to know which character each glyph stands for. PDF Textfix reads the same sources a copy does: the ToUnicode map, the encoding and the glyph names. A glyph whose character it cannot work out is kept exactly as it is: an edit can change the text around it but cannot remove it. If no glyph of a line is known, the line is locked, and its lock says: “No character of this line is known, so it cannot be edited.” A Type 3 line is locked too: “This text is drawn with a font made of pictures, so PDF Textfix cannot write new text in it.” Right-to-left and joined scripts are locked the same way. The Issues pane (⌥⌘I) lists every locked line with its reason.

What this does not do

PDF Textfix does not repair a file’s character maps, run OCR or make scanned text editable. When a line’s text cannot be mapped, the app tells you rather than guessing.

If the text will not select at all, rather than pasting wrong, the cause is different: see can’t select, copy or search text in a PDF.

Questions people ask

Why does only one paragraph paste as gibberish?

Each font in a PDF has its own map. A heading in one font can copy cleanly while body text in a subset without a map does not. Run pdffonts and look for the font whose uni is no and whose encoding is not a standard one.

Why do I get boxes when I paste?

The paste holds characters your font cannot show, often from Unicode’s Private Use Area, a range with no agreed meaning. The file’s maps give nothing better; OCR or a fresh export is the way back.

Why does PDF text pasted into Word turn into symbols?

Word receives the same characters any other app would. Paste into TextEdit too: if the result is just as wrong, the cause is the PDF’s map, and a fresh export or OCR is the fix.