You need the text out of a scanned PDF because it is a contract you must search, an old archive you want to feed to an LLM, or an invoice whose values have to land in a system.
If you already ran OCR on it and the result was garbage, we get it. It is not you, and it is rarely the OCR engine alone. OCR was built for upright, sharp, high-contrast printed text, and a bad scan breaks those assumptions one at a time: it is too small, it is tilted, it is noisy, the page has columns or a table. The fix is to find which assumption broke and deal with it. Last evaluated: October 2026.
The short answer: check that the file is really a scan, repair the image problems you can (resolution, rotation, noise), pick an engine that tolerates the rest, and when the problem is structure (tables, columns) or you need reliable fields, stop fixing pixels and use an agentic document processing system.
First: is it really a scan?
If you can select and copy text in the PDF, it already has a text layer and you do not need OCR: a parser reads that layer directly. Many "scans" turn out to be PDFs where only some pages are images, which is why a mixed file can look half right. Check page by page before you spend time on image repair.
The checklist: what usually goes wrong, and what to try
We ran Tesseract, EasyOCR and PaddleOCR on the same synthetic images, each one with a single problem, and scored the output as one minus the edit distance to the true text (1.0 is a perfect copy). These are easy images by construction and we did not preprocess them, so read the scores as a map of where each engine breaks, not as a benchmark. The test is in Best Python OCR libraries.
| Problem | What to try | What we saw (Tesseract / EasyOCR / PaddleOCR) |
|---|---|---|
| Low resolution | Rescan at 300 DPI or more; upscale before OCR if you cannot rescan | At 100 DPI: 0.995 / 0.979 / 0.989. At 50 DPI: 0.505 / 0.245 / 0.957 |
| Tilted page | Deskew the image first | Rotated 15 degrees: 0.000 / 0.223 / 1.000 |
| Page upside down or sideways | Detect and fix orientation | Rotated 90 degrees: 0.165 / 0.096 / 0.106 for all three. Tesseract detected the rotation correctly, so a rotate step fixes it |
| Noise and blur | Clean and sharpen before OCR, or choose an engine that copes | Heavy noise and blur: 0.000 / 0.202 / 0.851 |
| Low contrast | Usually fine; raise contrast if the text is faint | 1.000 / 0.989 / 1.000 |
| Two columns | Split the page into columns before OCR | 0.489 for all three: the words were complete but the reading order was wrong |
| Tables | Use a layout-aware parser; OCR gives text, not structure | Small table read as text: 0.227 / 0.943 / 1.000, and none returned table structure |
| Accents and other languages | Install the language file for the language you read | English-only Tesseract on a Spanish paragraph: 0.967 overall but nine accented words dropped; with the Spanish file, 0.993 and none dropped |
| Handwriting | Do not expect reliable OCR; plan for human review | Not tested: the fonts we used only look handwritten |
Two things the numbers hide. First, one wrong word in a total matters more than a hundred slightly noisy words, so score the fields you care about, not the whole page. Second, we did not test preprocessing at all, which is exactly what Tesseract's own documentation recommends for skewed or low-resolution input. Deskewing and upscaling will move several of these rows. The plain finding is that engines differ a lot on raw bad input, and none of them fixes layout. See also Is Tesseract accurate enough for production?.
When fixing the image stops being enough
Preprocessing pays off for resolution, tilt and noise. It does not solve the problems that are not about pixels:
- Structure. Columns, tables and forms need a system that understands layout, not just characters.
- Fields, not text. If the goal is an invoice number or a total, you still have to find it, type it and know how sure you are.
- Volume and variety. A pipeline of deskew, denoise, language packs and per-layout rules becomes a project that you maintain.
That is where the difference between OCR and intelligent document processing starts to matter; we explain it in IDP vs OCR, and the cost side of building it yourself in OCR API vs open source.
The solution: an agentic IDP with OCR
An agentic IDP puts OCR, layout analysis and extraction in one workflow, and picks how hard to work per document. In anyformat the Parse step has four modes, and the docs recommend starting on Standard and moving up or down only where the results justify it:
| Mode | What it does | Use it for | Credits per page |
|---|---|---|---|
| Flash | Reads the PDF's own text layer, no model call; OCRs pages that have no text layer | Born-digital PDFs at volume | 7 |
| Fast | One OCR pass on the strongest engine, no LLM correction | Clean scans and simple layouts | 12 |
| Standard | Page-by-page parsing with reading-order correction | Most documents and tables; the default | 25 |
| Agentic | Adaptive, multi-step parsing, strongest on dense tables | Complex layouts where Standard is not good enough | 100 |
For a poor-quality scan, start on Standard. If a page comes back wrong, move that document type up to Agentic; if a set of scans is clean, Fast is enough. Every extracted value comes back with a confidence score and the text and page it was read from, so a reviewer can fix the doubtful values in seconds instead of rereading the scan. Set a confidence threshold and send what falls below it to a person. If the next step is fields, see how to extract structured data from a PDF with an LLM; if it is tables, extracting tables from a PDF; if it is retrieval, PDF to markdown for LLMs.
Try it on your worst scan: the Free tier includes 50,000 credits with no credit card, enough to run your ugliest documents through each mode and compare.
How to check the result
Do not judge OCR on a clean page. Take 20 of your worst pages and:
- Write down the text or the values you expect for each, and compute the same score on your files. The scoring function is in our OCR libraries post; it reports one number per page and never prints the text, so it is safe to log.
- Compare engines or modes on the same pages, not on different ones.
- Count what a person still has to fix. The share of pages that pass with no human touch is the number that predicts your cost.
- Test with fictional or consented documents. Scans often contain personal data, and OCR output ends up in logs.
What it costs
anyformat's pricing is credit-based, per page and per operator. A credit costs €0.001 on Business and €0.0015 on Free and pay-as-you-go, and the per-page rates are in the credits docs. For a 10-page scan, Parse alone is:
| 10-page scan, Parse only | Credits | Business (€0.001) | Free / pay-as-you-go (€0.0015) |
|---|---|---|---|
| Fast | 120 | €0.12 | €0.18 |
| Standard | 250 | €0.25 | €0.38 |
| Agentic | 1,000 | €1.00 | €1.50 |
Extraction is billed separately, 35 credits per page in Standard and 150 in Agentic. Open-source engines cost no license but cost engineering time and, for the heavy ones, a large environment: in our test the EasyOCR and PaddleOCR setups were around 800 MB each.
Limits, stated plainly
- Handwriting and very low-resolution photos stay the weak spot of every approach. Plan a review step.
- We have not measured anyformat on the synthetic images above, so this page makes no claim about how it scores on them. Test your own pages.
- Preprocessing was not part of our test. Results on your files after deskewing or upscaling will differ.
- Accuracy depends on your documents. Before you rely on any vendor's headline figure, ours included, test your own worst pages.
Frequently asked questions
Why is OCR bad on my scanned PDF?
Usually because the scan breaks the assumptions OCR makes: low resolution, a tilted or rotated page, noise, low contrast, or a layout with columns and tables. Find which one applies and fix that first.
How do I improve OCR accuracy on poor-quality scans?
Rescan at 300 DPI or more, deskew and fix the orientation, clean noise and blur, install the right language, and check the result against text you know. Engines also differ a lot on raw bad input.
What resolution do I need for OCR?
300 DPI or more is the usual guideline, and Tesseract's documentation says it works best there. In our test, one engine scored 0.505 at 50 DPI and another 0.957.
Can OCR read handwriting?
Not reliably. Most OCR engines are designed for printed text; plan for human review.
Do I need OCR if I can select the text?
No. A PDF with a text layer can be read directly, and a parser is faster and cheaper than OCR.
Which engine is best for bad scans?
It depends on the problem. In our synthetic test PaddleOCR scored highest on rotated, noisy and low-resolution images without preprocessing, and Tesseract was the lightest and fastest on clean text. For tables, columns or fields, an engine is not enough.
When should I use an API instead of open source?
When the problem is structure or fields rather than pixels, when volume makes the maintenance cost larger than the license, or when you need confidence scores and evidence. See OCR API vs open source.
Start with your worst scans. Upload the pages that break your current OCR, choose a Parse mode, and see the values with their confidence and their evidence on the page. The Free tier includes 50,000 credits with no credit card.
Disclosure: anyformat sells document extraction; the OCR test used synthetic images and is described in our linked post, and the comparison criteria and dates are stated.
