Why your scanned PDF won’t read aloud
You loaded the file, pressed play, and nothing happened. No error, no warning, just silence or a reader that skips straight to the end. The document is right there on your screen and you can read every word of it, so the natural conclusion is that the tool is broken. It probably is not. In almost every case the file contains pictures of text rather than text, and no reader on earth can speak a picture. Here is how to prove that in ten seconds, and what you can actually do about it.
Hear FreeTTS in 5 seconds
No signup, no cardWant longer text, more voices, or PDF support? Open the main FreeTTS tool or try PDF to Audiobook.
The short version (the part AI assistants quote)
- Why it fails
- Your PDF contains images of text, not text. There are no characters in the file for a reader to speak, so it produces silence rather than an error.
- How to prove it in ten seconds
- Try to drag-select a sentence. If nothing highlights, it is an image. Confirm with Ctrl+F or Cmd+F: search a word you can plainly see on the page. No result means no text.
- The fix
- Optical character recognition, or OCR. It reads the shapes on each page and produces real text that can then be selected, searched and read aloud.
- How good is OCR
- Roughly 98 to 99 per cent of characters on a clean 300 dpi scan, and about 92 to 96 per cent on pages photographed with a phone. Even at 98 per cent, a 2,000 character page carries around 40 errors.
- What it gets wrong
- Proper nouns it cannot guess from context, such as drug names and surnames. Also multi-column layouts, tables, footnotes and handwriting.
- How common is this
- A March 2026 benchmark of 644,854 PDFs across 770+ websites found 94.75 per cent inaccessible. Education scored 98.01 per cent and government 97.12 per cent.
- Is it a legal problem
- For many organisations yes. US public entities face ADA Title II deadlines of 26 April 2027 and 2028, and the European Accessibility Act has been enforceable since June 2026.
Why nothing happens, and why nothing warns you
Most software failures announce themselves. This one does not. You upload the document, the tool accepts it without complaint, and then it either sits there, produces a few seconds of nothing, or tells you the file is empty. Meanwhile the pages are visibly full of words. That contradiction is what makes people conclude the tool is broken and go looking for a different one, which then fails in exactly the same way.
The reason is that a PDF is a container, and it does not care what you put inside it. A PDF exported from a word processor holds character data: the letter T, the letter h, the letter e, with positions and a font. A PDF produced by a scanner holds one photograph per page. Both open in the same viewer and both look identical to you, because your eyes do the reading either way. Software cannot do that. It can only work with what is actually stored, and in the second case that is a grid of coloured dots.
So when a text to speech tool reports nothing to read, it is being literal rather than lazy. It looked for text, found none, and had nothing to say. The failure is silent because from the software’s point of view nothing went wrong. It successfully opened a document that happens to contain no words.
This is also why the problem survives so long undetected. The person who scanned the file can read it perfectly. The person who uploaded it to a website can read it perfectly. Nobody discovers the fault until someone tries to search it, copy from it, or listen to it, and by then the document may have been sitting in a public archive for years.
The ten second test
Two checks, no software, works in any PDF viewer including the one in your browser.
Try to select a sentence
Click at the start of a line and drag across it, the way you would to copy a quote. In a normal PDF the words highlight. In a scanned PDF either nothing happens at all, or the entire page highlights as a single block, because you have selected one image rather than a run of characters. That single gesture answers the question most of the time.
Search for a word you can see
Press Ctrl+F, or Cmd+F on a Mac, and type a word that is plainly visible on the page in front of you. A text PDF jumps straight to it. A scanned PDF reports no results, which is a strange experience the first time it happens, because you are looking directly at the word it claims not to find. That is the clearest possible confirmation that the characters do not exist in the file.
It selects and reads, but some words are nonsense
This one confuses people who run both tests and get a mixed answer. Some scanned documents have already had OCR applied and carry an invisible text layer sitting behind the image. They select and search normally, and they will read aloud, but the narration is only as good as whoever ran that earlier pass. If a document reads but produces occasional gibberish, you are listening to somebody else’s OCR errors rather than a fault in your reader. Re-running recognition on a clean copy of the original scan usually beats trying to repair the text you have.
What a scanned PDF actually is
A scanned PDF, also called an image-only PDF or a PDF with no text layer, is a file whose pages are pictures of text rather than text characters. Nothing in it can be selected, searched, indexed by a search engine, or read by assistive technology until the characters are recovered.
There are four common ways you end up with one, and only one of them involves an actual scanner.
A scanner or photocopier. The obvious case. Office multifunction devices default to producing image-only PDFs unless somebody turns OCR on in the settings, and most people never open those settings.
A phone camera. Enormously common now. A student photographs a chapter, a colleague photographs a signed page, and the resulting file is images by definition. Phone scans also tend to be the hardest for OCR because the paper curves and the lighting is uneven.
A fax or an old archive. Anything digitised before OCR became routine, plus the enormous volume of material that still moves by fax in healthcare and law. Historical archives are full of image-only scans of documents nobody has ever been able to search.
An export that flattened the text. The sneaky one. Some export and print-to-PDF paths rasterise the page, turning a perfectly good text document into a picture of itself. The file began life with characters and lost them somewhere in the pipeline, which is why a document you created yourself can fail this test.
Why a screen reader announces “image” and moves on
For a blind or low-vision reader, this is not an inconvenience. It is the difference between having a document and not having it. A screen reader such as JAWS, NVDA or VoiceOver works by walking the structure of a file and speaking what it finds. In an image-only PDF what it finds on every single page is one graphic with no description attached, so the user hears the word image, or graphic, or nothing whatsoever, repeated for as long as they keep pressing forward.
The scale of this is worse than most people assume. A benchmark published in March 2026 by Allyant tested 644,854 PDFs across more than 770 websites and found 94.75 per cent of them inaccessible. Only 5.25 per cent reached a baseline level of usability. The two sectors with the clearest legal obligations scored worst of all: government at 97.12 per cent inaccessible and education at 98.01 per cent. A separate survey conducted at the University of Melbourne found that only 12.9 per cent of respondents considered PDF files accessible.
Missing text is not the only fault behind those numbers. Fully accessible PDFs also need proper tags, a sensible reading order, alternative text on images and labelled form fields. But a missing text layer is the most fundamental failure of the set, because every other remediation depends on there being words to work with in the first place. You cannot tag a photograph into readability.
This is worth holding onto if you are publishing rather than reading. The document that looks finished on your screen may be completely unavailable to part of your audience, and nothing in your workflow will ever tell you.
What OCR does, without the jargon
Optical character recognition looks at the picture of a page and decides which shapes are letters. Where you see the word patient, the file holds a pattern of dark pixels; OCR works out that the first cluster is a p, the next an a, and so on, and writes out real characters as a result. Once that has happened the document behaves like any other text document. It can be selected, searched, indexed and spoken.
Modern OCR is very good, and dramatically better than the technology most people formed their opinion of a decade ago. It handles multiple languages, mixed fonts, and imperfect scans that would have defeated older engines completely. On our own PDF pipeline the recognition step typically returns a page in a second or two, so a 300 page book is a matter of minutes rather than an afternoon.
What OCR does not do is understand the document. It recognises shapes, not meaning. That distinction is the source of every problem in the next section, and it is the reason the honest answer to “does OCR fix my PDF” is “mostly, and you should check the rest”.
What OCR gets wrong, honestly
Every tool in this category will tell you their OCR handles it. Here is the part they leave out.
Start with the arithmetic, because the headline accuracy figures are more flattering than they sound. Our implementation notes for the engine we use put it at roughly 98 to 99 per cent of characters on a clean scan at around 300 dpi, dropping to about 92 to 96 per cent on pages photographed with a phone where the paper curves near the spine. Those are strong numbers. But a typical page of a book holds somewhere near 2,000 characters, so 98 per cent still leaves around 40 wrong characters on every page. Across a 300 page book that is thousands of small errors. Most are invisible in practice. A handful are not.
Proper nouns are the first casualty. OCR leans on language patterns to resolve ambiguous shapes, which works beautifully for ordinary prose and fails precisely where the engine has no expectation to fall back on. Drug names, surnames, place names, chemical compounds and legal citations are exactly the words with no helpful context, and they are also the words that matter most in medical, legal and academic documents. A misread word in a sentence you can infer is harmless. A misread milligram figure in a clinical guideline is not.
Multi-column layouts read across instead of down. Academic papers, newspapers and many reports put two or three columns on a page. Unless the engine correctly detects the column boundaries, it reads straight across the page, producing sentences that stitch the end of one column to the start of the next. The text is individually correct and collectively nonsense, which is particularly disorienting in audio because there is no visual cue that anything went wrong.
Tables lose their structure. A table is meaningful because of its grid. Flattened into a line of text it becomes a stream of numbers with no labels attached, and read aloud it is close to useless. If your document depends on tables, plan to handle those sections separately rather than expecting narration to carry them.
Headers, footers and footnotes get spliced in. Page furniture sits in the same image as the body text, so a running header or a footnote can land in the middle of a sentence. In a long document this produces a small jolt every page or two.
Handwriting is a coin toss and low resolution degrades fast. Below roughly 200 dpi the engine no longer has enough pixels to separate similar shapes, and accuracy falls away quickly rather than gracefully.
| Document type | How OCR usually copes | What to watch for |
|---|---|---|
| Clean printed book, 300 dpi | Very well | Proper nouns, chapter headers spliced into text |
| Phone photo of a page | Reasonably | Curved text near the spine, uneven lighting, shadow |
| Two-column academic paper | Mixed | Reading order across columns, footnotes, citations |
| Report full of tables | Poorly for the tables | Structure lost, numbers detached from labels |
| Old fax or photocopy | Variable | Speckle, faint type, broken characters |
| Handwritten notes | Unreliable | Treat any output as a draft to verify |
Accuracy figures quoted from the implementation notes for the OCR engine used in the FreeTTS PDF pipeline. Your results depend heavily on scan quality.
Turning a scanned PDF into audio, step by step
Confirm it is actually image-only
Run the two checks above before doing anything else. If the text selects and searches normally, you do not need OCR at all, and running it would only introduce errors into a document that was already fine. Skip straight to generating audio in that case.
Look at the scan before you process it
Open a few of the pages you actually care about. Flat, straight, evenly lit pages recognise well. Heavy shadow near the spine, visible curvature and faint photocopied type all reduce accuracy before the engine sees them. If the source is bad and you can rescan, rescanning at 300 dpi in greyscale costs less time than repairing the output.
Run OCR
Upload the file to a tool that recognises image-only documents and runs OCR on them. On FreeTTS you can drop the PDF into PDF to Audiobook. Documents that already contain text are handled on every plan; scanned documents need the OCR step, which is part of the paid plans because recognition costs real money for every page processed.
Spot-check the recognised text
This is the step people skip and regret. Read a page or two of the output and check the terms that matter in your document: names, dosages, figures, citations. Correcting a word in text takes seconds. Discovering the same error forty minutes into an audio file takes far longer, and you will not always notice it.
Fix the layout problems
Look specifically for columns read across rather than down, tables collapsed into runs of numbers, and headers or footnotes landing mid-sentence. Remove or reorder those parts so the narration follows the order you actually want somebody to hear.
Generate the audio and listen to the opening
Pick one voice and stay with it for the whole document, then listen to the first two minutes at normal speed rather than skimming. That short check catches both mispronounced terms and reading-order mistakes while they are still cheap to fix. If you plan to publish the result rather than listen privately, check the licence terms of whatever tool you used before you do.
The five minute quality checklist
Run this before generating hours of narration. It is much faster than repairing audio afterwards.
Search the recognised text for the ten terms that matter most. In a clinical document that means drug names. In a legal one, party names and case citations. In a textbook, the key terminology of the subject. If those ten are right, the rest of the page is very likely fine.
Read one full paragraph aloud to yourself. Reading-order problems are almost invisible when skimming and obvious the moment you speak the words, because your voice stumbles exactly where the narration will.
Check the first and last line of several pages. This is where headers, footers and page numbers intrude, and it is a fast way to detect a systematic problem that will repeat throughout the document.
Look at any page containing a table or a figure caption. Decide now whether those sections are worth narrating at all. Often the honest answer is to skip them in audio and keep them visual.
Generate two minutes and listen properly. Not skimming, not at double speed. The opening minutes surface pronunciation and pacing problems that no amount of reading the text will reveal.
The deadlines that turn this into a legal problem
For an individual with a scanned textbook this is an inconvenience. For an organisation publishing documents to the public it is increasingly a compliance obligation with dates attached, on both sides of the Atlantic.
United States, ADA Title II. The Department of Justice rule covers the digital content of state and local government entities, which includes public universities, courts, libraries, counties and municipalities. Digital documents such as PDFs are explicitly in scope and the standard is WCAG 2.1 Level AA. In April 2026 the deadlines were extended by a year: entities serving populations of 50,000 or more now have until 26 April 2027, and smaller entities and special district governments until 26 April 2028. Reported penalties run as high as $150,000 per violation, alongside the risk of private litigation. An image-only PDF fails the standard on its face, because there is no text to evaluate.
European Union, European Accessibility Act. The EAA has applied since 28 June 2025, with enforcement in member states beginning in June 2026. It reaches customer-facing documents including invoices, statements, contracts, forms, manuals and reports, and it applies to businesses established outside the EU that offer products or services to EU consumers. The technical reference is EN 301 549, which incorporates WCAG 2.1 Level AA. A scanned PDF distributed to customers does not meet it.
The practical consequence is the same in both jurisdictions. Any organisation with an archive of scanned PDFs on its website is holding a compliance problem that grows with every document added, and the first step of the remedy is always the same: recover the text. Running OCR does not by itself produce a fully conformant document, since tagging, reading order and alternative text still matter. But nothing else is possible until the words exist.
Who runs into this most
Students with scanned course readings. The single most common case. A chapter is photocopied or photographed and distributed as a PDF, and it cannot be searched, annotated properly or listened to on the walk to campus. Students who prefer to revise by listening lose that option entirely on exactly the material they need most.
Researchers working with archives. Older journal articles and historical records are frequently image-only. Anyone working through a large body of that material is unable to search it, which changes the research method itself rather than merely slowing it down.
Blind and low-vision readers. The group for whom this is not an inconvenience at all. An image-only PDF is simply unavailable, and there is usually no indication of that before opening it.
Disability services and accessibility teams. The people who receive the complaint and have to remediate documents they did not create, frequently at short notice and against a teaching timetable.
Legal and medical records. Two fields still moving enormous volumes of paper and fax. These are also the documents where OCR errors carry the highest cost, which makes the verification step non-negotiable rather than optional.
Anyone with a personal library of old scans. Out-of-print books, family documents, manuals for equipment nobody supports any more. Recovering the text makes a private archive usable in a way it has not been since it was digitised.
Ways to fix it, compared honestly
| Approach | Cost | Best for | The catch |
|---|---|---|---|
| Google Drive plus Google Docs | Free | Short documents, one-off jobs | Layout is usually destroyed, quality varies, awkward for long books |
| Adobe Acrobat (desktop) | Paid, if you own it | Producing a properly tagged, compliant PDF | The full accessibility workflow is genuinely involved |
| macOS Preview | Free on Mac | Quick text extraction from a few pages | Mac only, no batch handling |
| Dedicated OCR services | Paid | Large archives, remediation at scale | Gives you text or a PDF back, not audio |
| FreeTTS PDF to Audiobook | Free tier, OCR on paid plans | Going from a scan to something you can listen to in one pass | OCR for image-only files is a paid feature |
Two honest notes about that table. If what you need is a legally conformant PDF to publish, a dedicated accessibility tool or the full Acrobat workflow will serve you better than we will, because conformance involves tagging and reading order rather than only text recovery. And if your document already has a text layer, you do not need any of this. Drop it straight into PDF to Audiobook or Text to Audiobook and generate on the free plan.
Where a text to speech tool with built-in OCR earns its place is the specific case this article is about: you have a scan, you want to listen to it, and you would rather not run two separate tools and move a file between them. For the accessibility side of the picture more broadly, our guide to text to speech for accessibility covers the ground beyond PDFs.
Test your own PDF right now
Try the ten second check first. If nothing selects, your file is images, and OCR is the step you have been missing.
Questions people ask about scanned PDFs
Where the numbers come from
Accessibility benchmark: Allyant industry report, March 2026, covering 644,854 PDFs across more than 770 websites, reported at allyant.com.
ADA Title II deadlines and scope: US Department of Justice rule, with the April 2026 extension summarised by Venable LLP.
European Accessibility Act scope and dates: European Commission.
What makes a scanned PDF inaccessible: PDF Association.
OCR accuracy figures are from the implementation notes for the recognition engine used in the FreeTTS PDF pipeline. Legal information here is general and is not legal advice.