The Best Free OCR Tools for Documents & AI Pipelines

Most OCR comparisons stop at a table of tools and a vague claim about accuracy. That is not much use, because the interesting question is not which engine wins a benchmark. It is how good your text has to be before the thing you are building on top of it works at all, and that question has an answer you can compute.

A 5% character error rate sounds tolerable. It means that an invoice number will come out of your pipeline intact less than half the time. This article covers the arithmetic that connects scan quality to retrieval quality, and then the tools. If you just need text out of a document today, our Free OCR tool runs in the browser and never uploads your file.

TL;DR

• Accuracy is measured as character error rate, an edit distance divided by the length of the truth.
• Errors compound across a term: at 5% CER a 16 character identifier survives intact only 44% of the time.
• That is why exact-match search over OCR'd documents fails while the text still "looks fine" to a human reader.
• 300 DPI is not a superstition. It falls out of the requirement that a capital letter be at least 20 pixels tall.
• Tesseract, PaddleOCR and the newer VLM-based extractors all beat each other on different documents. Choose by layout, not by leaderboard.

How OCR accuracy is actually measured

The standard metric is character error rate. Align the OCR output against the ground truth, count the substitutions $S$, deletions $D$ and insertions $I$ needed to turn one into the other, and divide by the number of characters $N$ in the truth:

Word error rate is the same formula over words. CER is the more honest number for documents, because a single mangled character inside a long word inflates WER dramatically while barely affecting whether a human can read it.

Good scans of clean printed text land under 1% CER. Phone photos of creased paper under office lighting are commonly 3% to 8%. Handwriting is a different problem entirely and classical OCR should not be expected to solve it.

Why a "small" error rate destroys retrieval

Here is the part that gets skipped. CER is a per-character probability, but nothing you care about is a single character. You care about an invoice number, a part code, a customer name. If errors are roughly independent, the probability that a term of $k$ characters comes through completely intact is:

Exponential decay in the length of the term. That is a brutal function, and it is why a document that reads perfectly well to a person can be useless to a search index.

The consequences are worth being precise about, because they hit different parts of a pipeline differently. Exact-match and keyword search break hardest: the term either matches or it does not, so a single wrong character makes the document invisible. Embedding-based retrieval degrades more gently, since a vector is robust to a corrupted character or two, but it degrades in a way that is much harder to notice, because nothing errors, results are simply a little worse forever. And an LLM reading the passage will often reconstruct a mangled English word from context, which is the dangerous case, because it will do exactly the same confident reconstruction to a mangled invoice number and produce a plausible number that was never on the document.

So the rule follows from the maths: if identifiers matter, you need CER well under 1%, and no amount of clever prompting downstream will repair a digit that was never captured.

Where the 300 DPI rule comes from

Everyone repeats "scan at 300 DPI" without saying why, which makes it sound like folklore. It is not. OCR engines need a capital letter to be around 20 pixels tall before their classifiers become reliable. A capital letter is about 70% of the nominal point size, and there are 72 points to an inch, so:

Solve for the resolution that clears the 20 pixel floor:

For 10 point body text, that is 206 DPI. For the 8 point small print where the terms and the account numbers live, it is 257 DPI. Round up for safety margin and you arrive at 300, which is where the rule comes from.

There is a ceiling too. Past roughly 600 DPI you gain no accuracy and pay for it in memory and processing time, because you are now faithfully capturing the texture of the paper.

The tools, and what each is actually for

The last row deserves a warning. A vision language model does not fail the way an OCR engine fails. Tesseract, when it cannot read a digit, gives you a wrong digit or nothing. A VLM asked for an invoice total will, if the figure is unreadable, sometimes return a number that is entirely plausible and entirely invented. For anything financial or legal, that failure mode is worse than a blank, because it is invisible. Ask for confidence scores, and validate with checksums and range checks where the format allows it.

Preprocessing earns more than tool switching

Before you swap engines, fix the image. In practice the returns are ordered like this: deskew first, since even 2 degrees of rotation measurably hurts line segmentation; then binarize adaptively (Sauvola or Otsu) so that uneven lighting stops eating the strokes; then upsample if the glyphs fall under the 20 pixel floor, because an interpolated glyph classifies better than a tiny one; and only then denoise, gently, because aggressive denoising erodes thin strokes and turns an "e" into a "c".

A well-prepared image through Tesseract will routinely beat a badly-prepared one through anything else, which is why "which OCR tool is best" is usually the wrong question to be asking first.

From text to a working pipeline

Once the text is out, it becomes tokens, and tokens are either a bill or a memory constraint. OCR output is often far more token-dense than it looks, because layout artefacts, repeated headers and stray characters all cost the same as real words. Run it through our Token Counter before you commit to a chunking strategy, and see how to count tokens and why it affects your bill for what that does to the invoice.

If the documents are confidential, and invoices and contracts usually are, the entire pipeline should stay on infrastructure you control. Our Free OCR runs client side for that reason. Netra helps teams fine tune, accelerate and deploy extraction models on their own hardware, so sensitive documents never leave the building. If you self host the model, the LLM VRAM Calculator will size the GPU.

FAQ

What CER do I need? For reading prose, under 5% is usually fine. For extracting identifiers, you want under 1%, because errors compound exponentially with the length of the term.

Is a VLM better than Tesseract? On messy layouts, often. On a clean scan it is slower, more expensive, and it can invent values, which Tesseract will not do.

Why is my RAG worse after adding scanned documents? Almost certainly OCR errors breaking exact-match retrieval and quietly polluting your embeddings. Measure CER on a sample before blaming the retriever.

Can I OCR a phone photo? Yes, but expect several percent CER unless you deskew, correct the lighting and ensure the text is large enough in frame. Crop tightly and get the paper flat.

Free tools from Netra

All of these run in your browser. No signup, and your documents are not uploaded to us.

• Free OCR: images and PDFs to LLM-ready text, entirely client side.
• Web to Markdown: the same job for web pages, without the markup.
• Token Counter: OCR output goes into a prompt, and this tells you what it will cost.
• LLM VRAM Calculator: size the GPU if you run the extraction model yourself.
• Fine-Tuning Memory Calculator: for fine-tuning a model on your own document layouts.
• Limbus: local-first image segmentation, useful for isolating regions before OCR.
• sam3.c: SAM3 inference in pure C.

References

• Tesseract, Improving the quality of the output, the source of the 20 pixel and 300 DPI guidance.
• PaddleOCR.
• docTR, document text recognition.
• Sauvola and Pietikainen, Adaptive document image binarization.