docTR

docTR is an open-source Python library for adding document OCR to software and research workflows. It suits developers who need control over detection, recognition, layout, and deployment rather than a packaged OCR application. Its broad pipeline and customization are compelling, but the Python 3.11-or-newer requirement narrows compatibility.

Overview

docTR builds OCR around a two-stage process: pretrained predictors first detect text and then recognize it. A separate layout predictor identifies regions such as tables, figures, and headers, so applications can preserve useful page structure instead of receiving an undifferentiated text stream. That makes it a stronger foundation for document automation and research than a text-only extractor, while still requiring developers to integrate the library into their own software.

The project is free under the Apache License 2.0. Installation is available through pip or Git, with official Docker images in GitHub Container Registry. Pretrained weights download on first use and remain cached locally, which is convenient for repeated runs but should be considered when provisioning isolated or ephemeral environments.

Key features

• OCR pipeline: Detection and recognition predictors cover the core task of finding and reading text in PDFs and images. The two-stage design gives developers separate points to work with when building a processing pipeline.
• Layout analysis: Region detection for tables, figures, and headers adds document structure to OCR output. It is useful when later code must route or interpret page regions, although the documented capability is analysis rather than a complete business-field extraction system.
• Input and output choices: docTR can load PDFs, images, and web pages. HTML requires the optional html extra, an installation consideration for mixed-source workflows. Results can be rendered as plain text or exported as a nested, JSON-serializable dictionary, making the output practical for application code and data pipelines.
• CPU and GPU inference: Predictors are described as optimized for both CPU and GPU execution. That lets a deployment balance hardware cost against throughput instead of locking the project to one class of machine.
• Custom models: Users can train detection, recognition, layout, and table-structure models when pretrained weights are not suitable. This is a significant advantage for specialized documents, but it also shifts data, training, and maintenance work to the user.
• Ecosystem and deployment: Models can be loaded and shared through the Hugging Face Hub. A minimal REST API template and browser demo provide starting points for serving or showcasing a pipeline, while the contrib module adds an artefact detector for logos, QR codes, and barcodes and requires onnxruntime.

Pricing

Plan	Price	Includes
docTR open-source Python library	free	Python 3.11 or higher; install with pip, Git, or Docker

There is no trial period because the library is free rather than a time-limited service. The plan has no published seat, usage, or renewal charge; your practical costs are the engineering and infrastructure needed to run and customize it. It is the natural fit for individual developers, research projects, and teams comfortable operating their own Python or containerized pipeline.

Platforms

docTR supports API, Linux, macOS, self-hosted, and Windows environments, with desktop listed as its primary platform. Python 3.11 or higher is required. The self-hosted orientation, Docker option, and CPU/GPU inference suit controlled deployments, while AWS Lambda users must disable multiprocessing and place the model cache under /tmp to meet Lambda's write restrictions.

Who it's for

Choose docTR when you are building document automation or research software in Python and need OCR plus page-region information. It is particularly well suited to teams that expect to train their own models, share weights through Hugging Face, or expose a pipeline through an API. It is a poor fit for users wanting a finished desktop application, and the Python version requirement can rule it out of older environments. HTML-heavy workflows also need the extra installation step.

Pros and cons

Pros

• Free Apache-licensed software with pip, Git, and Docker installation paths.
• Combines text recognition with layout regions such as tables, figures, and headers.
• Supports custom detection, recognition, layout, and table-structure training.
• Offers CPU and GPU inference plus REST and browser-deployment starting points.
• Produces plain text or structured JSON-serializable output for downstream code.

Cons

• Requires Python 3.11 or newer, limiting compatibility with older stacks.
• It is a development library, so users must assemble and operate the surrounding workflow themselves.
• HTML input needs the optional html extra, and artefact detection needs onnxruntime.
• Custom models require users to supply training data and handle the resulting maintenance burden.

Alternatives

Tesseract OCR is the better choice for a broadly deployed, free Apache 2.0 OCR engine with Android, API, Linux, macOS, self-hosted, and Windows support. Pick PaddleOCR instead when Android or iOS access and an official API tier with a daily 20,000-page parsing limit matter more than docTR's Python-centered customization. OCRFeeder suits Linux users seeking free GPL software. Choose OCRmyPDF for self-hosted PDF processing across API, Linux, macOS, and Windows when depending on external OCR and PDF tools is acceptable. GNU Ocrad is a free Linux and self-hosted alternative. FreeOCR.AI fits users who prefer a hosted freemium service, with a $10 monthly Pro plan for 10,000 credits. Open-Capture is a free GPLv3 option with no user limit across API, Linux, self-hosted, and web deployments. Surya offers a free pay-as-you-go plan with request and concurrency limits for API-oriented use.

Verdict

docTR is a strong choice for Python developers and researchers who need free, self-hosted OCR with layout analysis and the option to train specialized models. Its main reason to choose it is the control it gives over a complete, CPU-or-GPU document pipeline; its main reason to look elsewhere is the Python 3.11-or-newer requirement and the integration work inherent in a library rather than a finished OCR product.