Open Source OCR: Best Open Source OCR Engines

Last updated August 2026.

The best open source OCR engine for most teams is PaddleOCR, because it is the only major one that ships layout analysis and table recognition alongside text recognition, under a permissive Apache 2.0 license. Tesseract remains the safest long-term choice for plain text in more than 100 languages. EasyOCR is the fastest to get running. Surya is the most capable on modern documents but its model weights are not free for larger companies. None of the four extracts business fields such as a vendor name or a sales tax amount, and that gap is what decides most real projects.

The four engines, side by side

Every fact in this table comes from each project's own repository documentation.

The license line most comparisons skip

Open source and free for commercial use are not the same statement, and Surya is the clearest example. Its code is Apache 2.0, but the model weights carry a modified OpenRAIL-M license that permits research, personal use, and companies under $5M in funding or revenue. Above that threshold you need a paid commercial license. The code being open tells you nothing about the weights, and the weights are the part that does the work.

Tesseract, PaddleOCR, and EasyOCR are all Apache 2.0 with no revenue condition, which is why they still dominate production deployments. Tesseract's documentation does note that it depends on other packages under different licenses, including Leptonica under a BSD 2-clause license, so a legal review of the full dependency tree is still worth an hour of somebody's time before you ship.

Is Tesseract still good in 2026?

Yes, for what it does. Tesseract 5 uses an LSTM neural engine introduced in version 4 that is focused on line recognition, and it reads more than 100 languages out of the box. It is stable, permissively licensed, and available in every package manager. Its limits are equally clear: no GUI, no document layout analysis, and results that depend heavily on how well you preprocess the image.

That last point is the one that surprises people. Tesseract's own guidance is that you need to improve the quality of the image to get good results, which in practice means you write a preprocessing stage: deskewing, thresholding, denoising, and resolution normalization. On clean 300 DPI scans it performs well. On a faded thermal receipt photographed at an angle, most of your engineering time goes into the preprocessing rather than the OCR call.

Which open source OCR is best for tables and layout?

PaddleOCR. Its PP-StructureV3 pipeline adds layout analysis, table recognition, and formula recognition on top of text detection, and it explicitly targets complex elements including text, tables, formulas, and charts. Version 3.7.0 shipped in June 2026 and its PP-OCRv6 models cover 50 languages in a single unified model, including Chinese, English, Japanese, and 46 Latin-script languages.

It also scales down further than the alternatives. PaddleOCR publishes models at roughly 1.5M, 7.7M, and 34.5M parameters, so the same toolkit can run on an edge device or a GPU server, across NVIDIA GPUs, Intel CPUs, and other accelerators. If your documents have tabular structure that matters, that combination is hard to beat at zero license cost.

Do you need a GPU to run open source OCR?

Not strictly, but the gap is large enough to change your architecture. EasyOCR runs CPU-only with a single flag and still recommends a CUDA-capable GPU for practical performance. Surya publishes concrete numbers: roughly 5 pages per second on an RTX 5090 against 0.108 pages per second on Apple Silicon with the Metal backend. That is a difference of more than forty times.

Translate that into a queue. At 0.108 pages per second, ten thousand pages takes about 26 hours on one worker. At 5 pages per second it takes about 33 minutes. If your month-end close involves thousands of documents, CPU inference is not a cost saving, it is a deadline problem, and you are now provisioning and monitoring GPU workers as part of your finance stack. Teams that go this route usually end up needing a real deployment story, with zero-downtime releases and server monitoring for the inference service, well before they need better OCR.

What do the OCR benchmarks actually measure?

This is worth knowing before you pick an engine based on a leaderboard. OmniDocBench covers 1,651 PDF pages across 10 document types, and its composite score is calculated as one third text edit distance, one third table TEDS, and one third formula CDM. A third of the headline number is formula recognition. olmOCR-Bench uses 1,403 PDFs and 7,010 unit tests, of which 3,385 assertions, roughly 48 percent, are math formula assertions.

Neither benchmark contains a single receipt or invoice. The receipt datasets that do exist are old and narrow: SROIE covers 626 training and 347 test images across four fields, CORD is Indonesian, and FUNSD is forms. So if you are choosing an OCR engine for business paperwork, published benchmark rankings are measuring something close to the opposite of your workload. Run your own worst documents through each candidate instead, and see our notes on OCR accuracy for how to score the result honestly.

What open source OCR does not give you

All four engines return characters, lines, and coordinates. None returns a vendor name, an invoice date, a subtotal, a sales tax amount, or a line item. That distinction sounds pedantic until you look at the output: knowing the page contains the string 8.25 is not the same as knowing 8.25 was the sales tax, and reconstructing that meaning is where the actual work lives.

Closing the gap yourself means building a field-extraction layer: regular expressions and positional rules per vendor layout, or a trained model, plus validation that catches a total which does not equal the sum of the lines. Then you maintain it. Every supplier who redesigns an invoice breaks a rule, and nobody finds out until a wrong number is already in the ledger. This is the same build-versus-buy calculation we work through in LLM OCR vs Tesseract, where language models close part of the gap and introduce a different failure mode by inventing plausible numbers.

When self-hosting genuinely wins

Three situations make it the right call. Very high volume, where per-page cloud billing at scale exceeds the cost of hardware you already own. Data residency or air-gapped requirements that rule out sending documents to a third party at all. And unusual document types where you intend to train your own models anyway, so you need control of the pipeline end to end.

Outside those, the arithmetic usually favors a managed service. Cloud text OCR runs about $0.0015 per page with AWS Textract and $1.50 per 1,000 pages with Azure Read, verified from vendor pricing in August 2026. Ten thousand pages a month of raw text is $15. One engineer spending two days a month keeping an inference service healthy costs considerably more than that, and it never appears in the OCR line of the budget. The full per-page comparison sits on our OCR API pricing page.

How to choose, in practice

Start from the output you need, not the engine. If you need searchable text from documents in many languages and you have engineering capacity, Tesseract is the low-risk default. If your documents have tables and structure that matter, use PaddleOCR. If you want something working this afternoon for a prototype, EasyOCR has the shortest path. If you are evaluating Surya, check your funding and revenue against the $5M threshold first.

If what you actually need is receipts and invoices turned into spreadsheet columns, none of these four is the answer on its own, and no amount of tuning changes that. A field extractor returns the vendor, date, tax, total, and line items directly, which is the difference between a text file and a bookkeeping import. Our comparison of the best OCR software separates the four product categories in this market, and the OCR receipt scanner covers the extraction workflow for receipts specifically.

Frequently asked questions

What is the best open source OCR engine? PaddleOCR for most teams, because it adds layout analysis, table recognition, and formula recognition under Apache 2.0 with more than 100 languages. Tesseract is the safer long-term default for plain multilingual text. Both are genuinely free for commercial use, unlike some newer projects whose model weights carry revenue-based restrictions.

Is open source OCR as accurate as paid OCR? On clean printed text, often yes. The difference is not character accuracy but what comes back. Paid document extraction services return named fields such as vendor, date, tax, and total, while open source engines return text and coordinates. You supply the interpretation layer, and maintaining it is the real ongoing cost.

Can Tesseract read receipts? It can read the characters on a receipt, with quality depending heavily on image preprocessing. It cannot tell you which of those characters is the merchant, the date, or the total, because Tesseract performs no field labeling. Extracting receipt data with Tesseract means writing and maintaining that parsing layer yourself.

Is PaddleOCR better than Tesseract? For documents with tables, mixed layouts, or formulas, yes, because PaddleOCR ships structure analysis that Tesseract does not include. For straightforward text extraction in a wide range of languages with maximum stability and packaging support, Tesseract is still an entirely reasonable choice.

Is EasyOCR still maintained? Its most recent release is version 1.7.2 from September 2024, and the project remains widely used with a large community. Handwriting support is still listed as upcoming rather than available. For a new production deployment in 2026, PaddleOCR is the more actively developed option.