docTR: a two-stage OCR pipeline you assemble yourself

The two-stage split is the whole product

docTR does not ship one monolithic OCR model. The README describes end-to-end OCR as a two-stage approach: text detection, which localizes words, followed by text recognition, which identifies the characters in each word. Both stages are configurable. The quick tour shows the constructor taking a detection architecture and a recognition architecture as separate arguments: ocr_predictor(det_arch="db_resnet50", reco_arch="crnn_vgg16_bn", pretrained=True). That is the design decision everything else follows from. If your documents are clean scans of printed text, the pairing barely matters. If they are noisy, skewed, or full of unusual glyphs, you can replace one half without retraining or revalidating the other. The cost is that you now own a composition problem: two models, two failure modes, and a detection error that silently truncates what recognition ever sees.

Who this is actually for

The library targets Python developers who need to turn PDFs and images into structured text inside their own infrastructure. The README frames the output as parsing textual information, localizing and identifying each word, and it points at integration guidance rather than at an API endpoint. The presence of a Docker image link and a Colab quick tour suggests two intended entry points: a notebook for evaluation and a container for deployment. This is not a product for someone who wants to upload a file and receive JSON from a vendor. It is for a team that has decided OCR belongs inside its own stack, whether for data residency, cost control at volume, or the need to swap models. The Slack community link and the Gurubase assistant link indicate that support runs through community channels, not a paid support tier described in the README.

Input handling: PDF, image, URL, multi-page

Document input goes through DocumentFile, which the README shows with four constructors. from_pdf takes a path to a PDF. from_images takes a single path or a list of paths for multi-page documents. from_url fetches a webpage, and the README notes this requires weasyprint to be installed, so that path adds a dependency with its own system-level requirements. Once loaded, the document is passed directly to the model as a callable: result = model(doc). The result is a Document object with a nested structure of Page, Block, Line, Word and Artefact, and result.export() converts it to a nested dict that the README describes as more appropriate for JSON. That nesting is worth reading before you write a parser, because the shape of the exported dict determines how much flattening work you inherit.

Layout detection and the KIE predictor

Two optional layers sit on top of plain OCR. Passing detect_layout=True to ocr_predictor attaches detected regions to every page, and the README lists example types including Title, Text, Table, Page-header and Page-footer. Each region carries a type, a confidence and a geometry, and the README shows iterating over result.pages[0].layout to print them. That is region classification, not field extraction: you get boxes and labels, and you decide what they mean. The KIE predictor goes further by allowing a detector with multiple classes, so a detection model can be trained to find specific things such as dates and addresses, and the README states that the whole pipeline is already set up for you. The distinction matters when scoping work. Layout detection is usable out of the box with pretrained weights; a multi-class KIE detector implies you have or will produce training data for those classes.

Rotation settings are a real configuration trap

The README devotes a section to rotated documents and the three options interact in ways that are easy to get wrong. assume_straight_pages=True fits straight boxes directly on the page and returns straight boxes, which the README calls the fastest option. Setting export_as_straight_boxes=True converts final localizations to straight boxes regardless of page orientation. With assume_straight_pages=False, the predictor returns rotated bounding boxes, potentially with an angle of 0 degrees. If both options are False, the README states the predictor will always fit and return rotated boxes. The failure mode is quiet: choose assume_straight_pages=True on a corpus that contains rotated pages and you get fast, confident, wrong localizations. Choose rotated boxes when your downstream consumer expects axis-aligned rectangles and you get geometry your code cannot index. These are not tuning knobs; they are assumptions about your input that the library will not check for you.

Visualization and synthesis are debugging tools, not outputs

result.show() renders predictions interactively, and the README notes it requires matplotlib and mplcursors to be installed. result.synthesize() goes the other direction, rebuilding pages from predictions, with the README showing it fed into a matplotlib imshow call. Neither is a production output path. Their value is diagnostic: synthesize a page and compare it against the original to see whether detection dropped a column or merged two lines, which is far faster than reading nested dicts. The extra dependencies are also a reminder that the visualization path is optional and should not leak into a headless deployment image.

Maintenance, ownership and the licence

The README states plainly that docTR was originally created by Mindee and is now actively developed and maintained by t2k GmbH, with a link to that company's site for complex use cases. For anyone evaluating this for a long-lived system, that transfer is the single most important governance fact in the repository, more than any release cadence. The release history shows v1.0.0 in July 2025, v1.0.1 in February 2026 and v1.1.0 in August 2026, which indicates the project is still moving but not on a fast cadence. The licence is Apache-2.0 per the repository badge and the LICENSE file reference. Apache-2.0 is permissive and includes a patent grant, but it does not automatically cover separately distributed pretrained weights or third-party model components. Nothing in the supplied material states the terms for the pretrained checkpoints, so treat that as something to confirm yourself rather than something to assume. This is not legal advice. The practical upgrade cost comes from the two-model design: a version bump can change either the detection or the recognition half, and your regression suite has to cover both.

Where docTR is the wrong choice, and what to compare it against

The clearest case against docTR is a document type that is already handled well by a single end-to-end model. If your inputs are clean, single-column, upright pages and you only need the text, the two-stage pipeline hands you two models to host, two sets of weights to version and a detection step that can silently delete a line before recognition ever runs. A managed OCR API removes that operational surface entirely: you send bytes, you receive text, and the vendor owns the model. The trade is control and data path, and for regulated documents or high-volume batch jobs that trade often goes the other way. A second comparison is against a general-purpose vision framework that includes detection and recognition heads. The difference in approach is that docTR defines the pipeline for you, including the Document, Page, Block, Line, Word hierarchy and the export format, whereas a general framework leaves that contract to you. If your downstream schema already exists, docTR's nested output is convenient. If you need a different contract, you are writing a translation layer either way. Finally, the KIE predictor is not a substitute for a document understanding service: it gives you a multi-class detector wired to a recognizer, not a trained extraction model for your fields.

Editorial conclusion

Adopt docTR if you need a self-hosted OCR pipeline where you choose the detection and recognition architectures, and you are willing to manage model weights and framework dependencies yourself. Do not adopt it if you want a single supported end-to-end model with a fixed output contract, or if you cannot accept that the maintainer changed from Mindee to t2k GmbH. Before committing, verify three things on your own documents: whether the layout detection regions map onto the fields you need, whether the rotated-page settings you choose match your scan orientations, and which of the PyTorch or TensorFlow backends your deployment target actually supports. The repository is Apache-2.0 licensed, so check the licence text and any bundled model weight terms yourself rather than relying on the badge.

Official sources

1. License: Apache-2.0
2. mindee/doctr on GitHub
3. Project website
4. README
5. Releases