Tesseract is the most widely installed OCR engine in the world, it is genuinely good at clean English text, and it costs almost nothing to run. Three things almost nobody tells you: Google stopped developing it in August 2017, a page fed in rotated 270 degrees returns near-total garbage, and it emits no fields and no table structure at all.
Written for US engineering and procurement teams deciding whether to build on Tesseract. Every figure here comes from a primary source and the arithmetic is shown. Last updated September 2026.
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Free plan extracts the first 5 files, the rest unlock when you upgrade
Uploading...
Before you write the parsing layer Tesseract does not give you, drop in the hardest document you have and see what finished, validated fields look like.
Tesseract is a free, Apache-2.0 licensed OCR engine that turns an image of printed text into text. It has 76,309 GitHub stars, supports more than 100 languages out of the box, runs on Linux, Windows and macOS, and version 5.5.3 shipped in July 2026. Since version 4 the recognition engine has been an LSTM neural network focused on line recognition, with the older character-pattern engine still available behind the --oem 0 flag.
The distinction that decides everything is this. Tesseract does optical character recognition. It does not do document data extraction. Those sound like the same job and they are not. OCR answers "what characters are on this page". Extraction answers "what is the invoice number, who is the vendor, and what are the line items". Tesseract answers the first question well and cheaply, and it does not attempt the second one at all.
The part that cuts against our own interest, said plainly. Tesseract is better than its reputation among people selling alternatives to it. On the independent OmniDocBench text evaluation it scores 0.096 edit distance on English against 0.071 for PaddleOCR, a gap of 0.025, and it beats EasyOCR outright. It runs on a $0.1785 an hour CPU instance with no GPU, which makes it the cheapest engine in this entire category to operate. If your job is "get the words off clean English pages so we can search them", Tesseract is very likely the right answer and you should stop reading here and go install it.
And the part that decides against it. Tesseract's own README lists its output formats: plain text, hOCR, PDF, invisible-text-only PDF, TSV, ALTO and PAGE. Read that list again looking for named business fields, or for a table with rows and cells. They are not there and no flag adds them. That is also why Tesseract appears nowhere on OmniDocBench's overall document-parsing leaderboard or its table-recognition evaluation, despite being on the benchmark's text evaluation. A system that emits no structure cannot be scored on structure.
No, and it has not been developed by Google since August 2017. This matters more than it sounds, because a large share of the people searching for this engine search for it as "Google Tesseract", and buy on the assumption that a hyperscaler stands behind it. Tesseract's own README settles it in one sentence, verbatim: "In 2005 Tesseract was open sourced by HP. From 2006 until August 2017 it was developed by Google." Before that it was Hewlett-Packard's, built in Bristol and in Greeley, Colorado between 1985 and 1994.
So the accurate description is an HP research engine that Google sponsored for eleven years and then handed back to the community. There is no Google support contract behind it, no Google SLA, and no relationship to Google Cloud Document AI, which is an entirely separate paid product. If a vendor or a consultant tells you that you are getting "Google's OCR" for free, that stopped being true nine years ago.
Keep the other half of this straight too. Google leaving did not kill the project and Tesseract is not abandoned. Version 5.5.3 shipped on July 24, 2026, it is the 36th release, and code was pushed to the repository on September 2, 2026, the day this page was written. What changed in 2017 is who pays for it, not whether it is maintained.
| When | What happened | Source |
|---|---|---|
| 1985 to 1994 | Built at Hewlett-Packard Laboratories, Bristol UK and Greeley, Colorado | Tesseract README, Brief history |
| 1996 | Ported to Windows | Tesseract README, Brief history |
| 1998 | C++ conversion work | Tesseract README, Brief history |
| 2005 | Open sourced by HP | Tesseract README, Brief history |
| 2006 to August 2017 | Developed by Google, an eleven year sponsorship that has now been over for nine years | Tesseract README, Brief history |
| 2017 onward | Community maintained. Version 4 introduced the LSTM neural engine | Tesseract README |
| July 24, 2026 | Version 5.5.3 released, the 36th release | GitHub releases API |
| September 2, 2026 | Code pushed to the repository on the day this page was written | GitHub repository API |
Yes, and the repository numbers are healthy for a project of its age. Here is the state of it, pulled from the GitHub API on September 2, 2026.
Good on clean English, poor on almost everything else, and catastrophic on one specific condition that scanning workflows produce constantly. The numbers below are from OmniDocBench, an independent CVPR 2025 benchmark of 1,651 PDF pages, which evaluated Tesseract 5.5. The metric is edit distance, where lower is better and zero would be perfect.
One methodological note, because it is easy to get this wrong. The benchmark reports these scores in separate column groups, and the groups are different slices of the corpus. The language scores and the rotation scores are not measured on the same pages, so a number in one table cannot be compared with a number in the other. We have kept them as two tables for that reason. Compare down a column, not across the two.
| Engine | English | Chinese | Mixed |
|---|---|---|---|
| PaddleOCR | 0.071 | 0.055 | 0.118 |
| OpenOCR | 0.070 | 0.068 | 0.106 |
| Tesseract-OCR 5.5 | 0.096 | 0.551 | 0.250 |
| EasyOCR | 0.260 | 0.398 | 0.445 |
| Surya | 0.057 | 0.123 | 0.164 |
| Mathpix | 0.033 | 0.240 | 0.261 |
| GOT-OCR | 0.041 | 0.112 | 0.135 |
| GPT-4o | 0.020 | 0.224 | 0.125 |
English is the story most people get wrong in both directions. Tesseract is not the disaster its detractors claim, at 0.096 against 0.071 for PaddleOCR and 0.070 for OpenOCR, and it comfortably beats EasyOCR at 0.260. It is also not competitive with a modern vision model, where GPT-4o scores 0.020. Chinese is where the age of the architecture shows: 0.551 against 0.055 for PaddleOCR, a factor of ten.
This is the finding that should decide your architecture if you take scans from the outside world. Tesseract handles a page rotated 90 degrees perfectly well, at 0.117. Rotate the same kind of page 270 degrees and it scores 0.969, which means the output is very nearly all wrong. That asymmetry is bizarre and it is real, and the practical consequence is that a document feeder loading a batch the wrong way round produces text that looks like text, passes any "did we get output" check you wrote, and is garbage.
| Engine | Normal | Rotate 90 | Rotate 270 | Horizontal |
|---|---|---|---|---|
| PaddleOCR | 0.060 | 0.015 | 0.285 | 0.021 |
| Tesseract-OCR 5.5 | 0.426 | 0.117 | 0.969 | 0.984 |
| EasyOCR | 0.360 | 0.970 | 0.997 | 0.926 |
| Surya | 0.104 | 0.634 | 0.767 | 0.255 |
| GOT-OCR | 0.091 | 0.562 | 0.966 | 0.097 |
| Mathpix | 0.180 | 0.038 | 0.185 | 0.638 |
| GPT-4o | 0.168 | 0.115 | 0.718 | 0.132 |
PaddleOCR on the same slice scores 0.285 at 270 degrees and 0.021 horizontally, so this is not a limitation of open engines generally. It is Tesseract specifically. If you build on it, orientation detection is not an optimization you add later, it is a required stage in your pipeline. Our fuller OCR accuracy comparison puts these engines against the commercial APIs, including the finding that the three biggest cloud document APIs publish no accuracy figure at all.
Seven, and the README names them exactly: plain text, hOCR (HTML), PDF, invisible-text-only PDF, TSV, ALTO and PAGE. For a developer the TSV mode is the one that matters, because it returns per-word bounding boxes and a confidence value, which is the raw material for everything you might build on top. What is missing from the list is the important part.
| Format | How you get it | What it gives you |
|---|---|---|
| Plain text | The default output | Words only. No positions, no structure |
| TSV | tesseract in.png out tsv | Per-word bounding boxes and a confidence value. The useful one for developers |
| hOCR | tesseract in.png out hocr | XHTML with text lines and regions |
| ALTO | An XML layout format used in digitization and archives | Text lines and regions |
| PAGE | An XML layout format used in document analysis research | Text lines and regions |
| tesseract in.png out pdf | The original image with a hidden searchable text layer | |
| Invisible-text-only PDF | tesseract -c textonly_pdf=1 | A text layer you merge with an images-only PDF |
| JSON | Not available | There is no JSON output mode |
| Named business fields | Not available | No invoice number, vendor, total or line items as values |
| Table cell structure | Not available | Not evaluated on the table benchmark, because none is emitted |
Not as structured data, and there is a clean way to demonstrate that rather than assert it. We parsed all ten tables in the OmniDocBench README on September 2, 2026 and counted where Tesseract appears. It is in the 12-entry text recognition evaluation and in the version list, as 5.5. It is absent from the 33-entry overall document-parsing leaderboard and absent from the 8-entry table recognition evaluation, where PaddleOCR, RapidTable, StructEqTable, GOT-OCR, Qwen2-VL and InternVL2 all appear.
That absence is not an oversight by the benchmark authors. It follows from the output list above. A table score measures how correctly a system reproduces a cell grid, and Tesseract does not emit one, so there is nothing to score. You get text and coordinates, and turning coordinates back into rows and columns is your code, your merged-cell edge cases and your silent data corruption when a column shifts. If table structure is the thing you actually need, our PDF table extraction page covers what the alternatives return, and PDF to CSV API covers the reconstruction gotchas in detail.
The most credible source on what an engine cannot do is usually the engine's own documentation. These are quoted verbatim from Tesseract's FAQ and its image quality guide.
| Situation | What the Tesseract docs say, verbatim | Where |
|---|---|---|
| Handwriting | "You can, but it won't work very well, as Tesseract is designed for printed text." | Tesseract FAQ |
| Barcodes and QR codes | "No. Tesseract is for text recognition." | Tesseract FAQ |
| Low resolution scans | "Tesseract works best on images which have a DPI of at least 300 dpi." | ImproveQuality |
| Noisy images | "Certain types of noise cannot be removed by Tesseract in the binarisation step, which can cause accuracy rates to drop." | ImproveQuality |
| Tightly cropped text | "If you OCR just text area without any border, tesseract could have problems with it." | ImproveQuality |
| Oversized borders | "Big borders can cause problems ("empty page")." | ImproveQuality |
Read those together and a pattern appears: Tesseract expects a clean, upright, well-cropped, 300 DPI scan of printed text. That is a reasonable expectation for a digitization project where you control the scanner. It is not a description of the documents that arrive from vendors, customers and phone cameras. If handwriting is part of your workload, handwriting OCR covers which engines actually support it.
The licence is free and the hardware is the whole bill, which is why this is the cheapest engine in the category to operate. The reason is that Tesseract does not want a GPU. We counted: the words GPU, CUDA and OpenCL appear zero times across Tesseract's core documentation, and the FAQ answers the speed question entirely in terms of CPU, verbatim: "Tesseract 4 also uses up to four CPU threads while processing a page."
So the right instance is a four-core compute box, not an accelerator. Rates below are AWS on-demand Linux in US East (N. Virginia), pulled from Amazon's public rate feed on September 2, 2026. Monthly figures are 730 hours, always on.
| Instance | vCPU | Memory | Per hour | Per month | Verdict for Tesseract |
|---|---|---|---|---|---|
| t3.medium | 2 | 4 GiB | $0.0416 | $30.37 | Burstable. Fine for trickle volume, not for a queue |
| c7i.large | 2 | 4 GiB | $0.0893 | $65.15 | Half the thread count Tesseract will use |
| c7g.xlarge | 4 | 8 GiB | $0.1450 | $105.85 | Graviton ARM. Tesseract is C++ and builds for it |
| c7i.xlarge | 4 | 8 GiB | $0.1785 | $130.31 | Matches the four CPU threads the FAQ describes |
| c7i.2xlarge | 8 | 16 GiB | $0.3570 | $260.61 | Two Tesseract processes, one per pair of cores |
| g4dn.xlarge (T4 GPU) | 4 | 16 GiB | $0.5260 | $383.98 | Wasted on Tesseract. This is the PaddleOCR box |
| g6.xlarge (L4 GPU) | 4 | 16 GiB | $0.8048 | $587.50 | Wasted on Tesseract. This is the dots.ocr box |
That $0.1785 an hour is the number worth remembering, because it is 4.51 times cheaper than the g6.xlarge that an open-weight vision model like dots.ocr requires, and 2.95 times cheaper than the T4 box that PaddleOCR benchmarks on. Being an old CPU engine turns out to be a real cost advantage.
We are not going to publish a single dollar-per-page figure for Tesseract, because that requires a throughput number and the project publishes none. We did not benchmark it ourselves either, so inventing one would be exactly the kind of confident wrong number this page exists to correct. What we can do is show the arithmetic on a c7i.xlarge at $0.1785 an hour, so you can drop in whatever throughput you measure on your own documents.
| If you sustain | 1,000 pages takes | Cost per 1,000 pages |
|---|---|---|
| 100 pages per hour | 10.00 hours | $1.79 |
| 250 pages per hour | 4.00 hours | $0.71 |
| 500 pages per hour | 2.00 hours | $0.36 |
| 1,000 pages per hour | 1.00 hour | $0.18 |
| 2,500 pages per hour | 0.40 hours | $0.07 |
| 5,000 pages per hour | 0.20 hours | $0.04 |
Sooner than for any other engine, because the hardware is so cheap. Below is the sustained throughput at which $0.1785 an hour becomes cheaper than paying per page, for each published managed rate. Note how low the first one is: at 119 pages an hour, roughly two a minute, Tesseract on a CPU box already undercuts a $1.50 per 1,000 pages text OCR API. For comparison, dots.ocr on its GPU needs 537 pages an hour to clear the same bar.
| To beat this managed rate | You must sustain | Which is about |
|---|---|---|
| $0.50 per 1,000 pages | 357 pages an hour, sustained | 260,610 pages a month |
| $1.50 per 1,000 pages (AWS Textract text, Azure Read, Google Enterprise OCR) | 119 pages an hour, sustained | 86,870 pages a month |
| $10.00 per 1,000 pages (Azure Layout, Bedrock Data Automation) | 18 pages an hour, sustained | 13,031 pages a month |
| $15.00 per 1,000 pages (AWS Textract TABLES) | 12 pages an hour, sustained | 8,687 pages a month |
| $30.00 per 1,000 pages (Google Form Parser) | 6 pages an hour, sustained | 4,344 pages a month |
Two honest caveats on that table. It compares a text-only engine against rates that in most cases buy you considerably more than text, so the comparison flatters Tesseract at the higher rates. And none of it counts engineering time, which is the real cost of self-hosting and is never $0.1785 an hour. Self-hosted OCR cost applies the same arithmetic across every open engine worth evaluating, and OCR pricing per 1,000 pages normalizes every managed vendor to one unit.
pytesseract is a thin wrapper that shells out to the Tesseract binary and hands you back a string. It is not an implementation of Tesseract and it does not bundle one, which is the single most common source of confusion. You install the engine through your operating system's package manager first, and only then does the Python package have anything to call. If you have ever seen TesseractNotFoundError, that is what it means.
On Debian and Ubuntu that is the tesseract-ocr package, on macOS it is brew install tesseract, and on Windows it is the UB Mannheim installer, which is why "tesseract ocr windows installer" is one of the most searched phrases about this engine. Then pip install pytesseract.
image_to_string throws away everything except the words. image_to_data with the TSV output gives you a bounding box and a confidence value per word, which is what you need if you intend to build any structure at all on top.
Resize to at least 300 DPI, deskew, denoise, and add a small border if the text is tightly cropped. Tesseract's own quality guide names every one of these. Most "Tesseract is inaccurate" reports are really "this scan was 150 DPI and slightly rotated".
The same shape applies in other languages: there are community wrappers for C#, Java, PHP and JavaScript, all of them calling the same C++ binary and all of them subject to the same output ceiling described above. Our OCR API for Python page covers what the managed alternative looks like in the same language, and OCR API for C# does the same for .NET teams.
We sell a document extraction product, so treat the second column with appropriate suspicion and check the numbers above yourself. The split is not close, though, and it falls along a single line: whether your deliverable is text or fields.
This is Tesseract's best case and it is a strong one. You want every word indexed, nobody reads the raw output, and an occasional character error costs you nothing. The searchable PDF output mode was built for exactly this.
A 0.096 edit distance on English at $0.1785 an hour is hard to argue with. If the pages are born-digital or scanned properly at 300 DPI and nobody needs fields, Tesseract is the economical answer.
It runs entirely offline on hardware you control, with no telemetry and no per-page metering. If that is the binding constraint, start here.
You need an invoice number, a vendor, a total and line items. Tesseract gives you a wall of text and coordinates. Everything between those two things is a project you own forever.
No cell grid is emitted, which is why it is not on the table benchmark at all. Reconstructing rows from bounding boxes is solvable and it is also where merged cells quietly corrupt your data.
Vendor PDFs, phone photos and fax-quality faxes arrive rotated, skewed, noisy and below 300 DPI. Every one of those is a documented Tesseract failure mode, and the 270-degree result is the one that will hurt.
DocuOCR is a cloud product, so if your documents genuinely cannot leave your network then this comparison is already decided and you should read on-premise OCR software instead. For everyone else, here is the trade in full.
| Question | Self-hosted Tesseract | Managed extraction API |
|---|---|---|
| What you pay | $130.31 a month per always-on c7i.xlarge, plus your engineers | A published per-page rate and nothing else |
| Licence cost | Zero. Apache-2.0, no revenue threshold | A contract |
| Cost when the queue is empty | The same $0.1785 an hour | Zero |
| What you get back | Text, word boxes and a per-word confidence | Named fields mapped to your schema |
| Table structure | You reconstruct it from coordinates | Returned as rows and cells |
| Confidence per business field | No. Per word, not per value | Standard on document products |
| Rotated or upside-down pages | You detect and correct them first, or you get garbage | Handled upstream of you |
| Handwriting | The project itself says it will not work well | Supported on document models |
| Validation and human review | You build it | Part of a workflow product |
| Export into accounting or an ERP | You build it | Included |
| Who is accountable when a number is wrong | You | A vendor with an SLA |
One more thing worth saying in Tesseract's favor, because almost nobody in this category can match it. The licence is Apache-2.0 with no revenue threshold and no commercial tier. Marker's model weights are free only below $5 million in revenue. MinerU requires a commercial licence above USD 20 million in monthly revenue. Tesseract has no such clause, and for a company that expects to grow, that is worth more than a few points of accuracy.
The engine that beats Tesseract on every column of the benchmark above, including 0.285 against 0.969 on rotated pages, and still runs on a $0.5260 T4.
Read itIBM's CPU-first parser at about $0.21 per 1,000 pages, the closest thing to Tesseract economics with actual document structure attached.
Read itA 3B open-weight reader with the best table score in its class, and the GPU requirement that makes Tesseract look cheap.
Read itSecond on the overall leaderboard, with the hosted API limits published in English for the first time.
Read itThe other 3B open reader, plus the correction to the 97 percent accuracy figure everyone repeats about it.
Read itThe full independent board, and the finding that AWS, Azure and Google publish no accuracy number at all.
Read itThe same hourly-rate arithmetic applied across every open engine, including the engineering time this page leaves out.
Read itWhat you need instead when a cell grid matters, and why coordinates are not a table.
Read itEvery managed vendor normalized, so the break-even table above has something honest to sit against.
Read itIf you only need text off clean English pages, Tesseract is cheap and good and you should use it. If what you actually need is an invoice number, a vendor, a total and line items, the honest question is how many months of engineering sit between Tesseract's TSV output and that. Upload the document you were about to write a parser for and compare.