Convert PDF to Readable Text When Copying Gives Gibberish
By Schema LawPublished Updated
To convert a PDF to readable text when copying gives gibberish, stop relying on the text stored in the file. Treat each page as a picture, run OCR on it, and export the newly recognized text. The stored text is wrong or missing, but the page you can see is still a sound source.
A page can look perfect and still be nonsense underneath. What you read on screen and what the computer reads are two separate things inside a PDF, and they can disagree. This post is about finding where they part company and making them agree again.
Why does text copied from a PDF come out as gibberish?
Copied text comes out as gibberish for one of two reasons. Either the PDF's fonts draw the right shapes without recording which characters those shapes stand for, or an earlier OCR pass guessed the words badly and saved its guesses as the text layer. The page image is fine in both cases.
Fonts with no route back to characters
A PDF does not store "the letter A". It stores a character code and a font, and the font draws a shape for that code. To copy or search, a program needs a way back from the code to a real character. The PDF specification, ISO 32000-1, covers this in section 9.10. It describes an optional ToUnicode entry in the font dictionary, holding a table "that maps character codes to Unicode values".
The word that matters is optional. When software writes a PDF without that table, or with a wrong one, the page still draws correctly because drawing never needed it. Copying is another matter. You get boxes, symbols, or letters consistently shifted, so that "Plaintiff" pastes as something like "Sodlqwlii".
Any program that writes PDFs can produce such a file. Candidates in a law office include a report printed to PDF from a case management or billing system, a form generated by a web portal, a document set in a special typeface, and a PDF that has been through several rounds of conversion between programs.
A poor text layer from an earlier OCR pass
The second cause is a scan that somebody has already run through OCR. A copier or a scan-to-email service can add a text layer on its own, without anyone asking for it. If the scan was faint, skewed or low in resolution, that layer can be full of errors: "rn" read as "m", "Tbe" for "The", digits swapped for letters, two columns woven into one line.
The two causes leave different fingerprints. Font trouble gives output that is wrong everywhere in the same way, often with no real words at all. Bad OCR gives mostly real words with scattered mistakes, and the mistakes are worst where the scan is worst.
Smaller causes worth ruling out
- Ligatures. Joined letter pairs such as "fi" and "fl" can paste as a blank or a single odd symbol, so "office" becomes "o ce". The rest of the text is fine.
- Reading order. The characters are right but arrive in the wrong sequence, with a footer in the middle of a sentence or columns interleaved.
- Missing spaces. Words run together because the file positions each word separately and stores no space character between them.
These three are annoyances in otherwise good text. A find-and-replace pass may be all they need.
Is the PDF unreadable to software, or only to you?
A PDF is unreadable to software when a program cannot get correct characters out of it, even though you can read every page. There are three ways that happens: no text at all, text that is wrong, and text whose font coding is broken. One paste test tells them apart.
Select a full sentence that you can read clearly on the page, copy it, and paste it into a plain text editor such as Notepad or TextEdit. Use a plain editor, not Word, so nothing is autocorrected on the way in.
| What the paste test gives you | What the file is | What it needs |
|---|---|---|
| Nothing can be selected | Image-only pages | OCR for the first time |
| The sentence, exactly as printed | Sound text | Nothing; copy or export as it is |
| Real words with scattered errors | A weak OCR layer | OCR again from the page images |
| Boxes, symbols or shifted letters throughout | Broken font coding | OCR from the page images |
| Correct words in the wrong order | A reading-order fault | OCR again, or reorder by hand if short |
| Copy is greyed out | A restriction set by the author | The sender's permission, not OCR |
The first row is the subject of the post on why you cannot copy text from a PDF, which explains how to tell whether a PDF has real text in more depth. The last row is not a recognition problem at all. If the file is locked, or will not open without a password, the post on how to convert a protected PDF to Word deals with what the lock allows.
Run a second test alongside the paste: search for a word that plainly appears on the page. Then search for a distinctive name. A file with broken font coding finds nothing, because the stored text does not contain the words you typed. A file with weak OCR finds some instances and misses others, which is the more dangerous result, since a partial answer looks like a complete one.
Do not assume the answer for page one holds for the whole file. Test a page from the middle and one from the end before you decide what the document needs.
Replacing a bad text layer by running OCR again
To replace a bad text layer, give an OCR tool the pages as pictures and take its reading in place of the stored text. The step that needs care is making sure the tool reads the picture of the page. Some programs skip any page that already contains text.
- Keep the file you received. Copy it and work on the copy. The original is the record of what arrived.
- Try the direct route. Upload the PDF to your OCR tool and look at the result for a page you tested earlier. If the sentence that pasted as rubbish now reads correctly, the tool worked from the page image and you can go to step 5.
- If the old text comes back, flatten the pages. Some desktop programs decline to recognize a page that already has text, or reuse what is there. Turn each page into a plain picture first: export the pages as images, or print the document to an image-based PDF, at 300 dpi or higher. Only do this to a file whose stored text is bad. Flattening good text throws away exact characters for nothing.
- Run OCR on the flattened copy.
- Choose an output that holds only the new text. Word and plain text exports contain the recognized characters and nothing from the old layer. They are the safest targets when your aim is to quote, edit or paste.
- If you need a PDF, test the PDF. Open the searchable PDF you get back and repeat the paste test on the same sentence. A correct paste means the file now carries good text.
- Name the result for what it is, for example
Calloway billing ledger (re-OCR 2026-10-08).pdf, and file it beside the original.
In Schema Law you upload a PDF, PNG or JPEG, the pages are read into text and tables, and you can look at each parsed page on screen before exporting. Compare the page you tested with what the parsed view shows. The export formats include Word, plain text and a searchable PDF, so you can take the text in whichever form the next task needs.
Two cautions apply to the flattening step. First, a file built from broken fonts is often small and sharp, since it was never scanned. Rendering it at 300 dpi gives an excellent picture for recognition, usually far better than any paper scan. Second, flattening removes bookmarks, links and form fields along with the bad text. If the document has a clickable table of contents you care about, keep the original for navigation and use the new file for text.
When a short passage is all you need
For one paragraph of a brief, you do not have to rebuild the file. Take a screenshot of the paragraph at a high zoom, run OCR on that image, and paste the result. Check it against the page. This is quicker than processing two hundred pages to quote three sentences.
PDFs with some readable pages and some image-only pages
A mixed PDF has sound text on some pages and none, or bad text, on others. It needs a page-by-page decision: keep the good text where it exists, recognize the rest. Running OCR across everything is simpler, but it swaps exact characters for recognized ones on pages that needed no help.
Mixed files are normal in legal work, because documents are assembled from parts:
- A typed motion with scanned exhibits attached behind it.
- A contract generated from Word with a scanned, hand-signed signature page.
- A closing binder combining lender PDFs, county recordings and faxed payoff letters.
- A production in which some documents were exported from email and others were scanned from paper.
Mapping the file
Before choosing a route, make a quick map. Jump through the file in steps of ten or twenty pages, and at each stop try to select a line. Note where the behaviour changes. Bookmarks and exhibit tabs usually mark the boundaries. For a 140-page filing the map might read:
| Pages | Content | Paste test | Action |
|---|---|---|---|
| 1 to 22 | Motion and memorandum | Exact | Keep as is |
| 23 | Signature page | Nothing selects | OCR |
| 24 to 31 | Declaration, typed | Exact | Keep as is |
| 32 to 118 | Exhibits A to F, scanned | Nothing selects | OCR |
| 119 to 140 | Exhibit G, system-generated ledger | Symbols | OCR from page images |
Two ways to handle it
Split, treat, rejoin. Extract pages 23, 32 to 118 and 119 to 140 into their own files, run OCR on those, and reassemble the PDF in the original order. The typed pages keep their exact text. This is the right route when the document will be filed, served or cited by page.
Recognize the whole file. Upload everything and take one consistent output. This is the right route when you want the text in Word or as plain text for your own analysis, and a few recognition errors on the typed pages are a fair price for one pass.
Whichever you choose, count pages before and after. A rejoined file with 139 pages has lost one somewhere.
The distinction between text taken from a file's own characters and text produced by recognition matters a good deal in discovery, where the two are tracked separately. The post on e-discovery OCR explains extracted text versus OCR text and why a production may carry both.
What does readable mean for a screen reader or a search index?
For a screen reader or a search index, readable means the file contains real characters, in the right order, that a program can extract without looking at the page. Software does not see the picture. If the stored characters are absent or wrong, the document is blank or false to every tool that depends on them.
The W3C's accessibility guidance puts the baseline plainly. Its technique on performing OCR on a scanned PDF to provide actual text says a document made of scanned images of text is "inherently inaccessible", because assistive technologies "cannot read or extract the words" and users cannot select, resize or reflow the text.
Different consumers of the text fail in different ways when the layer is bad:
| What reads the file | What it needs | What a bad text layer does |
|---|---|---|
| Screen reader | Characters in reading order | Reads nonsense aloud, or announces an empty page |
| Desktop or document-management search | Words that match what is printed | Misses the document, with no warning |
| Review or e-discovery platform | Extractable text for indexing and search terms | Search terms return too few hits |
| Copy and paste into a brief | Exact characters | Puts errors into a quotation |
| Translation or summarizing software | Coherent sentences | Works confidently from garbage |
Machine-readable is a low bar. A PDF with a sound text layer can be searched and read aloud, but that alone does not make it a tagged, accessible file. The post on how to make a PDF readable explains what being readable by a screen reader adds, and what to ask when a court, agency or client requires it.
There is also a quieter kind of unreadable. Text can be correct character by character and still useless in order: a two-column page read straight across, or a table read row-wise when the sense runs down the columns. Search still works on such a file. A screen reader user, or a program summarizing the document, gets sentences that never appeared on the page. When order matters, test it by pasting a whole page and reading it through.
If the file is a divorce petition, paste one page and read the requests in order. Search the parties' names, any request for child custody and any figure for child support. Spousal support language is easy to lose when the old text layer was garbage, so confirm that sentence against the image.
Spot checks that show the replaced text layer is sound
A new text layer is sound when sampled pages paste correctly, searches find what the page shows, and the characters that carry meaning match the image. You do not need to read every page to know this. Ten minutes of targeted checks on the worst pages tells you whether to trust the rest.
Run these on the new file, with the original open beside it:
- Repeat the failed paste. Take the same sentence that pasted as gibberish at the start. It should now paste exactly.
- Count pages. The new file must have as many pages as the original.
- Search for three things you can see: a party's surname, a dollar amount with its comma and decimal point, and a date. Each should be found on the page where you see it.
- Count a common term. Pick a word you know recurs, such as the defendant's name on a caption that repeats, and compare the number of hits with the number of pages it should appear on.
- Paste one full page from the worst-looking part of the file and read it against the image. Look at order as well as spelling.
- Check the confusable characters: 0 and O, 1 and l and I, 5 and S, 8 and B, and "rn" against "m". Read account numbers, case numbers and section references digit by digit. The post on why OCR gets numbers wrong lists which digits and letters get swapped most often.
- Check the edges. Headers, footers, page numbers and marginal stamps are where recognition is weakest.
- Look for leftovers. Search for a string of the old gibberish if you saved one. No hits means the old layer is not in the file you are about to use.
Pick the pages to sample on purpose. Include the faintest page, a page with a table, a page with small print, and the last page. If all of those pass, an ordinary page of clean type is very likely fine. If one fails, widen the sample around it.
Record what you did. A line in the file note is enough: which file, which date, which checks, who ran them. No OCR tool is right every time, and Schema Law does not mark passages it was unsure of, so the check is yours to make. When the text will be quoted to a court, read the quoted passage itself against the page image, word for word, whatever the spot checks showed. The guide to extracting text from a scanned PDF covers working with the plain text once you have it.