chandra

Turning documents into clean, structured data is one of the oldest unsolved problems in software. Classic OCR engines read characters well enough on tidy scans, but they fall apart on the things that matter most: multi-column layouts, dense tables, forms with checkboxes, handwriting, and mathematical notation. chandra, from the team at datalab-to, is a document digitization model that tackles exactly this messy middle. Rather than just transcribing text, it aims to reconstruct a document's structure and emit it as Markdown, HTML, or JSON with layout information intact. It is positioned for demanding OCR and layout extraction where the goal is not a rough text dump but a faithful, machine-readable version of the original page that downstream systems can actually trust.

chandra is built as a vision-language model fine-tuned on the Qwen-3-VL family rather than a traditional multi-stage OCR pipeline. Instead of chaining separate detection, recognition, and table-parsing steps, it processes a full page in a single pass: identifying content types, preserving table structure, reconstructing forms, extracting and captioning embedded images, and handling handwriting and equations together. That single-model design is what makes it distinctive, because layout decisions and text reading inform each other instead of being stitched together afterward. You can run it two ways. Locally, the weights are on HuggingFace and the CLI processes a PDF or image into an output folder; for throughput, a vLLM server backs the model. Alternatively, Datalab offers a managed API for those who would rather not host it.

The natural audience is teams doing serious document processing: digitizing archives, parsing invoices and forms, building retrieval pipelines over scanned reports, or extracting tables from financial and scientific PDFs. The breadth helps here. chandra covers tables, forms, handwriting, and over 90 languages, so it suits mixed real-world corpora rather than one narrow document class. Developers who already use Datalab's earlier projects, Marker and Surya, will find it a familiar step up for harder pages. Researchers and startups can run it locally on a GPU to keep data in house, which matters for sensitive records. Anyone needing structured Markdown or JSON output to feed into a RAG system, a database, or an LLM workflow is squarely in the target zone, especially where layout fidelity, not just raw text, is the deliverable.

The caveats are real and worth weighing before adoption. The biggest is licensing: the code is Apache-2.0, but the model weights ship under a Modified OpenRAIL-M license that is free only for research, personal use, and startups under a $2M threshold, and it carries a condition against competing with Datalab's own API. This is open weight, not OSI-open, so commercial teams must read the terms carefully before building on it. Second, local use effectively requires a GPU; this is not something you run comfortably on a laptop CPU, and serious throughput leans on a vLLM setup. Third, the benchmark claims, while strong on paper, are self-reported by the project, so independent verification on your own document mix is sensible. Real-world accuracy also varies with document complexity and degradation.

Against its commercial alternative, the Datalab API, chandra is less a free replacement and more the open-weight engine behind a paid service, with the managed option adding hosting, higher accuracy, zero data retention, and SOC 2 compliance for teams that need it. That framing should guide adoption. chandra is a strong fit when you have GPU capacity and want control and on-premise data handling, or when you qualify under the license and need broad, structure-aware digitization. It is too early, or simply the wrong path, for commercial self-use above the $2M threshold without checking the model license, and for anyone wanting a frictionless CPU tool or a guaranteed OSI-open dependency. Backed by an experienced team, it is credible and capable, but the license, not the technology, is the deciding factor.