Why Your PDF Copies as Gibberish (and How to Tell a Text PDF from a Scanned One)

You select a paragraph in a PDF, paste it into an email, and get a string of symbols or a row of empty boxes. Or you get nothing, because the selection never started. A PDF page only looks like text. What you can copy depends on what the file actually stores, and there are four common ways for that to be something other than plain characters. Each has its own symptom and fix, and a 30-second check tells you which you have.

Spec details below come from ISO 32000-1 (PDF 1.7), which Adobe publishes for free.

What a PDF stores when it “has text”

A PDF does not store words. It stores instructions: use this font, move here, draw glyph 37, then glyph 12. Those numbers are character codes, and they only mean something relative to the font. Display needs nothing more. Copying, searching and screen readers need one more step: turn the code into a Unicode character like A.

The spec (section 9.10.2) gives viewers a priority list. First is a ToUnicode CMap, a table in the font dictionary mapping each code to Unicode. Then come standard encodings such as WinAnsiEncoding and known CJK character collections. If none of those work, the spec is blunt: “there is no way to determine what the character code represents.”

Keep that sentence in mind. It explains most gibberish.

Cause 1: the page is a scan

A scanner or phone camera produces a picture of the page, and wrapping it in a PDF doesn’t change that. No character codes, nothing to copy.

Symptom: clicking and dragging selects nothing, or the whole page highlights as one block (that’s the image). Ctrl+F or Cmd+F finds nothing, even for a word you can see.

Some scanners run OCR and hide an invisible text layer behind the image. Those PDFs are searchable, but the copied text is only as good as that OCR pass.

Cause 2: a font with a missing or broken ToUnicode map

This is the “boxes and wrong letters” case. PDF makers commonly embed only a subset of each font, just the glyphs the document uses. The spec marks these with a six-letter tag and a plus sign, like EOODIA+Poetica. When a font is subset, the producing software can renumber the glyphs, so code 37 no longer lines up with the letter it would be in any standard encoding.

With a correct ToUnicode map, copying still works. Without one, or with a wrong one, the viewer guesses. The spec’s own example is a font using Identity-H encoding, where every code is just a 2-byte glyph index: “In the absence of a ToUnicode entry, no information would be available about what the glyphs mean.”

Symptom: text selects normally, word by word, so there is a text layer. But the paste is shifted letters or symbols, and search fails because the stored characters aren’t the ones you see.

Cause 3: text drawn as outlines

Design tools can convert type to shapes (in Illustrator it’s Type > Create Outlines). Printers ask for it so fonts can’t go missing. Each letter becomes a vector path, like a logo: sharp at any zoom, but with no character codes.

Symptom: the same as a scan (nothing selects, search finds nothing) except the page stays crisp when you zoom to 800%. A scan goes soft or blocky.

Cause 4: copy-protection permission flags

An encrypted PDF can carry a permissions value P in its encryption dictionary. Table 22 of the spec defines bit 5 as “Copy or otherwise extract text and graphics” and, from revision 3 on, a separate bit 10 for extraction “in support of accessibility to users with disabilities.” Bit positions count from 1 at the low-order bit.

These flags don’t scramble anything. Once a document is opened, the spec says, “there is nothing inherent in PDF encryption that enforces the document permissions.” Viewers are simply required to respect them, so the copy command is greyed out even though the text layer is perfect. That’s a different mechanism from a password you need just to open the file. We cover both in PDF owner vs user passwords.

Symptom: Copy is disabled or does nothing, and the file opens without asking for any password. The Security tab of the document properties shows that it is restricted.

How to tell which one you have

Four checks, quickest first:

1. Search for a word you can see. Ctrl+F (Cmd+F on a Mac). Found means there is a text layer with working Unicode. Not found means cause 1, 2 or 3.
2. Select all in the viewer. Ctrl+A or Cmd+A, then look at what highlights. Individual lines and words means a text layer. One big rectangle, or nothing, means an image or outlines. Zoom in to tell those two apart.
3. Look at the fonts. In Acrobat or Reader, File > Properties > Fonts lists every font, with “Embedded Subset” next to subset fonts. An empty list on a page full of words means there is no real text. On the command line, Poppler’s pdffonts prints a uni column that says whether each font has an explicit ToUnicode map:

name                    type      encoding  emb sub uni
DDPEFM+Helvetica        Type 1C   WinAnsi   yes yes no

That output is from the ISO 32000 PDF itself, and its text copies fine, so uni no is not a verdict on its own. The font uses WinAnsi, the spec’s second fallback. Suspect a broken map when uni is no and the encoding is Identity-H or a custom one.

4. Check size per page. Divide file size by page count. Text costs very little per page. A scan is a full image: a US Letter page at 300 dpi is 2,550 by 3,300 pixels, 8.4 million of them, before compression. A light file with many pages is almost certainly text. Treat it as a hint, since photos and fonts add weight too.

Symptom, cause, fix

What you see	Likely cause	Fix
Nothing selects, search finds nothing, page blurs when zoomed	Scanned image, no text layer	OCR the page
Nothing selects, page stays sharp at high zoom	Text converted to vector outlines	OCR the page (render it to pixels first)
Words select fine, pasted text is symbols or wrong letters	Subset font with missing or wrong ToUnicode map	Ignore the text layer and OCR the page
Pasted text has occasional wrong letters, layout is fine	A scanner’s invisible OCR layer	Re-OCR, or fix by hand
Copy is greyed out or silently fails	Permission flags (bit 5 clear)	Ask the owner for an unrestricted copy, or use a tool that reads the text layer directly
The file won’t open without a password	User password encryption	You need the password; then Unlock PDF

Getting clean text out

Our PDF to Text tool is built around that table. It runs in your browser and handles each page like this:

• Text layer first. pdf.js reads each run of text and its position. Runs on the same baseline are grouped into a line, lines are sorted top to bottom by their y position, and a space is added where the gap between runs looks like one.
• Automatic OCR for empty pages. If a page yields fewer than 20 non-space characters, it is treated as a scan. The page is drawn to a canvas at 2x scale on a white background and read by Tesseract. That covers causes 1 and 3 without you doing anything.
• Always OCR, for cause 2. A garbled text layer has plenty of characters, so it won’t trigger OCR on its own. Tick “Always OCR (ignore the text layer)” and every page is read from its pixels instead.
• Per-page output. Each page is badged “Text layer” or “OCR” with a confidence score, and pages under 60% get a warning. Copy everything or download a .txt file.

Your PDF stays on your device. The one external download is the OCR language model (English, Spanish, French, German, Portuguese or Italian), fetched from the jsDelivr CDN the first time you OCR a page.

The tool opens copy-restricted PDFs and reads their text layer directly, because pdf.js does not apply the copy flag when extracting text. The flag is still the author’s stated wish, so use that for files you have the right to use. Files that need a password just to open have to be unlocked first. Unlock PDF makes an image-based copy, so PDF to Text will then OCR every page of it.

Two limits. Because lines are built from y position, two-column pages interleave: line 1 of the left column and line 1 of the right end up on the same output line. Always OCR often does better there, since Tesseract finds text blocks first. And a scanned page with a 20-character stamp already in its text layer counts as a text page, so use Always OCR for those too.

When OCR is the answer, help it

Tesseract’s docs say it “works best on images which have a DPI of at least 300 dpi,” and that line detection “reduces significantly if a page is too skewed.” Our post on why OCR results go wrong has the full checklist.

For a photo or screenshot, use Image to Text. To inspect pages as images, PDF to Images renders them at up to 3x as PNG or JPEG. The Producer and Creator fields in PDF Metadata record the software that made the file. A scanner app or a print-prep tool there is a quick clue to which cause you’re dealing with.

Then drop the file into PDF to Text. The badges tell you which pages had real text and which were read from pixels.