OCR as a pipeline you can configure
docTR (Document Text Recognition) takes a different stance from the one-call OCR libraries: it exposes OCR as two stages you can configure. A detection model finds where the text is, a recognition model reads it, and you choose the architecture for each. That makes it the OCR library for teams that want to tune the speed-versus-accuracy trade-off rather than accept a black box. It is maintained by Mindee, a document-AI company, runs on PyTorch, and sits at 6,140 stars as of 2026-06, smaller than the headline engines but engineered with the polish of a maintained product.
The smaller star count undersells it. With only around 30 open issues, it is one of the better-maintained OCR projects on this list.
What it does
You build an ocr_predictor, point it at a document, and get back structured output organized by page, block, line, and word, with geometry for each. Because detection and recognition are separate, you can swap a faster detector for a more accurate one, or a recognition model better suited to your text, without rewriting your code. It also offers a KIE predictor for key-information extraction and orientation handling for rotated pages.
Install
The package name is the first thing to get right, because it is not doctr:
pip install python-doctrOptional extras add visualization and HTML support, for example pip install "python-doctr[viz,html]". You import it as from doctr.models import ocr_predictor. Note that as of version 1.0 the TensorFlow backend was deprecated, so docTR is now PyTorch-focused; if you were relying on TF serving, that path is gone.
Picking models
The flexibility is the feature, so the choice that matters is which models you wire together. Detection offers architectures like DBNet, LinkNet, and FAST, trading latency against accuracy. Recognition offers options such as CRNN, PARSeq, and ViTSTR, which differ on irregular and longer text. The default predictor is a sensible starting point; the value comes when you profile your documents and switch a component to fit.
Where it fits, and where it doesn’t
Reach for docTR when you want a customizable OCR pipeline, when you can profile and fine-tune to your document type, and when you want a maintained, Apache-2.0 library with a clean Python API. It suits engineering teams building document processing into a product rather than running a one-off script.
It is overkill if you just want text out of an image in one line, where EasyOCR is faster to adopt. It has a smaller ecosystem and fewer pretrained languages than the big engines, it no longer supports the TensorFlow backend, and custom-trained models can run much slower than the pretrained ones if you are not careful. It also does not do table-structure recognition out of the box.
docTR versus the other OCR engines
| docTR | EasyOCR | Tesseract | PaddleOCR | |
|---|---|---|---|---|
| Stars | 6,140 | 29,616 | 74,737 | 82,109 |
| Design | two-stage, swappable models | one-call API | engine plus wrappers | predictor API |
| Backend | PyTorch (TF deprecated) | PyTorch | C++ | PaddlePaddle |
| Customization | high | low | low | medium |
| Maintenance | active, few open issues | slowing | active | active |
Counts are from GitHub as of June 2026. EasyOCR is faster to adopt for a quick multilingual job but slowing in maintenance. Tesseract is the lightweight CPU classic. PaddleOCR is broad and strong on CJK. docTR’s distinct value is a configurable pipeline under active maintenance, at the cost of a steeper learning curve.
The star curve
The star curve climbs steadily rather than spiking, which fits a focused engineering library that grows by word of mouth among teams building document pipelines rather than by going viral. The continued, active release cadence into 2026 backs up the maintenance signal.
What the issue tracker warns you about
The issues here are the kind a maintained project surfaces rather than alarms. Custom detection models can be much slower than the pretrained ones, so profile before assuming a fine-tune is a free upgrade. Detection quality is sensitive to image scaling, so test at your real input resolution. Some users want broader language vocabularies and table-structure recognition, which are extension points rather than built-ins. And the TensorFlow deprecation in v1.0 is a real migration if you were on that backend. The low open-issue count is itself a positive signal about responsiveness.
Related
For a one-line multilingual start, see EasyOCR. For the lightweight CPU classic, see Tesseract. For strong CJK, see PaddleOCR. To turn parsed documents into Markdown for LLMs, see docling and unstructured. For what is trending, see the daily digest and the weekly report.
FAQ
What is the pip package name for docTR? It is python-doctr, not doctr. Install with pip install python-doctr, then import as from doctr.models import ocr_predictor.
docTR vs EasyOCR, which should I use? docTR gives you a configurable two-stage pipeline with swappable models and active maintenance, which suits a product. EasyOCR is a one-call API that is faster to adopt for a quick job. Choose docTR for a tunable pipeline, EasyOCR for time-to-first-result.
Does docTR still support TensorFlow? No. As of version 1.0 the TensorFlow backend was deprecated, and docTR is now PyTorch-focused. If you depended on TF serving, plan a migration.
Can I use docTR commercially? Yes, it is Apache-2.0, and it is maintained by Mindee, a document-AI company, so the license is permissive for commercial use.
Which detection and recognition models should I pick? Start with the default predictor, then profile your documents and switch components. Detection options like DBNet, LinkNet, and FAST trade speed for accuracy; recognition options like CRNN, PARSeq, and ViTSTR differ on irregular and longer text.