Datalab

Overview

Datalab turns documents like PDFs, scans, spreadsheets and slide decks into text and data your software can use.

It's worth a look if you're on an engineering team that wants one paid API to convert documents, pull fields out of them, split up bundled files and fill in forms, without running the AI models yourself. It fits best when you want Markdown, HTML, JSON or search-ready chunks, not just the raw text that basic OCR (software that reads text off an image) gives you.

Its open-source sibling, Marker, fits a different reader: a team that only needs conversion, can run its own GPU servers, and whose use is allowed under Marker's model license.

Four things to know before you commit. The API is still changing. Prices add up for every step you run. The paid on-premises version can't do everything the cloud version can. And Marker's code is Apache-licensed, but its model weights carry tighter rules than that suggests.

Independent editorial disclosure: Zarif Automates has no sponsorship, affiliate deal or commercial arrangement with Datalab. Datalab did not review or approve this article. It's based on public documentation, source code, release notes, benchmark files and repository issues, read on August 29, 2026. It is not a hands-on product test, a security audit, a legal opinion or a promise of performance. Test the service on your own documents, and ask Datalab to confirm commercial, privacy and security terms before you use it in production.

Four names, four different things

Datalab, Marker, Surya and Chandra are not four names for one product.

The Datalab API overview covers conversion, extraction, segmentation, form filling, pulling out tracked changes, custom processors and file operations. None of it answers right away. You send a document and get back an ID and a result URL. Then you either keep checking that URL or let Datalab call your server when the job is done, which is called a webhook.

The product moves quickly. The platform changelog says Chandra 2.2 reached the hosted API on July 10, 2026, and Forge became the main visual workspace for building pipelines in April 2026.

That range of features is the reason to pick Datalab over a basic OCR service. It doesn't do your whole job, though. You still need a queue, rules that check the results, a way for a person to review the bad ones, protection against saving the same record twice, and tests on your own documents.

What it does

Conversion into several formats

You can send a document by upload, by URL, or by pointing at a file already stored with Datalab. You get back Markdown, HTML, JSON or chunks.

The current API documentation lists fast, balanced and accurate modes, page ranges, image extraction, block IDs, word bounding boxes (the position of each word on the page) and checkpoints. A checkpoint is a saved copy of the parsed document. It matters when one parse feeds several later steps, because those steps don't have to convert the document again.

It reads more than PDFs. Datalab's file-type documentation includes common spreadsheet, Word, presentation, HTML, EPUB, image and PDF formats. Accepting a file type doesn't mean it handles every layout, embedded object, formula or language equally well, so test each format you rely on with its own set of sample files.

Pulling out fields, with a trail back to the page

Say you want the total, due date and vendor name from every invoice. You describe those fields in a schema, a structured list of what you want back, and send it to the extract endpoint. You can send the schema with each request or save it and refer to it by ID.

Saved schemas can be versioned, and an extraction can reuse a conversion checkpoint. Datalab's structured-extraction guide describes citations that point each extracted value back to the part of the page it came from. That's useful on a review screen. A reviewer can see exactly where an invoice total, policy number or contract date came from instead of trusting a number with no source.

This is a hosted Datalab feature. Marker 2.0 doesn't have it. The Marker 2.0.0 release notes say the old structured-extraction converter was removed, and point users to Datalab or to building their own LLM workflow. A team running Marker locally owns the schema prompt, the model provider, validation, citations, retries and review.

Splitting bundled files, and reusable pipelines

An insurance claim often arrives as one big PDF: a cover sheet, a police report, a repair estimate, photos and letters, all stuck together. Segmentation finds where each document starts and ends before anything else happens. A workable claim workflow looks like this:

1. Store the original packet under an ID that never changes.
2. Split it into the cover sheet, police report, estimate, photos and correspondence.
3. Convert only the sections that need searchable text.
4. Extract fields from the relevant sections using a schema pinned to a version.
5. Check required fields and totals in code.
6. Send missing, contradictory or low-confidence fields to a reviewer.
7. Save the approved record through a worker that won't write it twice if it retries.

Datalab's Forge interface can save and version chains of processors, and the API can run published pipeline versions. Versioning your schema and pipeline helps you reproduce a result, but it doesn't freeze the hosted model. The version policy says non-Enterprise users can receive model updates that may change output in small ways.

So keep a fixed set of test documents with known-good answers, and run them before and after any change you notice.

A workflow for feeding documents into search

RAG, short for retrieval-augmented generation, means letting an AI model look things up in your documents before it answers. Datalab's conversion is one step in getting documents ready for that. Don't let the parser write straight into your search database. Treat it as one contained stage:

1. Upload from a separate holding bucket, and record the file hash, source, file type and who's allowed to see it.
2. Convert to chunks or JSON with block IDs, and keep the page and bounding-box details.
3. Check the finished response's success flag, page count, parse-quality signal, and whether the text and images you expected are there.
4. Fetch the result before Datalab's documented one-hour expiration and store the approved copy in your own system.
5. Clean up headings, tables and metadata, then split into chunks and embed them.
6. Keep the document version, parser settings, model date and chunk IDs next to the index.
7. Spot-check retrieved passages against the source pages, and send incomplete parses to review.

Done this way, when search gives a bad answer you can tell whether the parser or the search was at fault. You can also rebuild the index without uploading sensitive files again.

A workflow for invoices

For invoices, convert first with checkpoint saving on, then pass the checkpoint to a saved extraction schema. Check line-item sums, tax, currency, vendor identity, duplicate invoice numbers and purchase-order matches in your own code, not in the model. Datalab's citations or bounding boxes can power a review screen that shows each field next to its source. Only an approved record should reach your accounting system.

The costs stack. Converting and then extracting means paying both rates. Sending a document straight to extraction can be simpler. A saved checkpoint pays off when the parsed version also feeds search, segmentation or several schemas. Measure both designs on your real invoices rather than assuming one is cheaper.

Marker 2.0 for running it yourself

Marker is still a good local option when you mainly need documents turned into Markdown, HTML, JSON or chunks, and your team can run the models.

Version 2.0.0, released July 20, 2026, needs Python 3.10 or later. The current repository describes balanced mode for quality on a GPU, fast mode for a cheaper path, and a no-OCR path for documents that already have usable text. Non-PDF formats need the full set of optional dependencies.

Running it yourself isn't free. GPU mode runs Surya through vLLM and an NVIDIA container setup. CPU or Apple Silicon uses a llama.cpp server. The bundled FastAPI helper is described by its own README as a small-scale server, and it doesn't offer every command-line feature. A production setup still needs a hardened service around it, queues, timeouts, monitoring, isolation between jobs, file-size limits and testing before each upgrade.

What the benchmark shows, and what it doesn't

Datalab reports that Marker 2 in balanced mode scored 76.0 overall and 83.5 on born-digital documents (files created on a computer, not scanned) on Ai2's 1,403-document olmOCR-bench. Fast and no-OCR modes trade some quality for speed.

The dataset and scoring tool come from a third party. But the published run and comparison are from Datalab. So this is a vendor-run result on a third-party benchmark, not a neutral evaluation.

The comparison also depends on settings. Open Marker issue #1066 argues that the published MinerU comparison used MinerU's pipeline backend instead of its newer default hybrid setup. The issue is still open. It doesn't cancel Marker's score, but "Marker beats MinerU" shouldn't be repeated without saying which MinerU backend was used.

User reports are another kind of evidence. Issue #1081 reports Marker 2.0 inventing and dropping text on a synthetic set of pages where ink shows through from the other side. Issue #1069 reports Markdown output silently cut short on one long document.

These are individual reports. They don't show how often it happens, nobody has independently reproduced them, and they aren't confirmed product-wide bugs. They do tell you what to test for: every page covered, nothing missing from the end, every source image accounted for, no invented text, and a clear error when something fails.

Pricing

Prices were verified August 29, 2026 against the live Datalab rate card and billing documentation. The live page was built August 28, 2026. Treat these as dated list prices, not a quote.

Some jobs cost more than the table shows. The rate card says about 5 percent of balanced and accurate extractions go over their fixed rate when a long document or a dense, repeated schema needs more compute. It lists schemas above 750 input fields as unsupported. Add-ons like chart understanding, infographic parsing and detailed bounding boxes are charged per page on top. EU processing adds 25 percent to the total.

The docs disagree on extraction pricing

The live rate card lists extraction tiers called fast, balanced and accurate at $6, $15 and $25 per 1,000 pages. The current structured-extraction guide describes two separate settings, mode and extraction_mode, and still lists only fast extraction at $6 and balanced extraction with verification, reasoning and citations at $25.

So don't assume mode=balanced gets you a $15 extraction. Before you forecast costs or deploy, confirm with Datalab which request fields it accepts, what the default is, what features come back, and which tier you're billed for.

Plans

Plans are separate from which processors you use:

• Free: $0, with a monthly allowance listed as $20 if you sign up with a work email or $10 with a personal email. Adding a card turns on pay-as-you-go.
• Team: $400 per month, which includes $400 of usage at the same rate card, plus production-level limits, admin MFA, and access to BAA/DPA and SOC 2 materials, according to current vendor pages.
• Enterprise: custom pricing for committed volume, SLAs, model pinning, running in your own cloud account or fully offline, and negotiated deployment terms.

Every processor you run is billed. Converting and then extracting the same 10,000 pages means paying for both. The billing documentation says each request is rounded up to the nearest cent, so very small jobs can cost more per page than the rate card suggests.

A few more conflicts are worth settling before you forecast. Older welcome copy still mentions a one-time $5 credit, while the billing docs and live rate card list the recurring $20 or $10 allowances. Official pages also disagree on free-tier rate limits and some bounding-box prices. Run your expected settings through Datalab's quote or cost-breakdown response, set spending caps on your API keys, and get the current commercial terms in writing.

Security, privacy and deployment

Datalab's security documentation says results expire one hour after processing, and using customer documents to improve its models is opt-in. That's more specific than "zero retention." Your files and results still get processed on Datalab's side, and you have to fetch the result before it expires. Leave the training opt-in off for confidential material unless the data's owner has approved it.

The vendor's security and billing documentation say it has completed a SOC 2 Type II audit and offers BAA/DPA agreements on qualifying plans. Those are the vendor's statements, not an audit done for this review. A regulated buyer should get the current report, the DPA or BAA, the subprocessor list, incident terms, deletion behavior, support-access controls and a diagram of which regions data passes through before signing off.

Account controls include app-based two-factor codes (TOTP), MFA enforced across a Team, spending limits per API key, key rotation and EU processing. Team MFA doesn't protect API keys, though. Create separate keys for development, staging and production, and give each one the smallest spending cap that works.

EU processing has a catch. The changelog says the processing endpoints need a file_url or a pre-uploaded datalab:// reference. Uploading a file directly to those endpoints doesn't support processing_location. The separate file-upload endpoint can store a file in EU infrastructure first.

The webhook docs currently disagree with each other. The security guide shows an HMAC signature in the header, a code that proves the message came from Datalab. The dedicated webhook guide describes a shared secret inside the JSON body, and warns that logging full payloads can expose it. Check what production actually sends using a staging setup. Either way, require HTTPS, compare secrets in constant time where that applies, ignore repeat deliveries by request ID, limit what the receiving server can do, and fetch the result with an API key kept on your server.

On-premises isn't the cloud product in a box

The paid on-premises version is not the full Datalab platform running on your servers. The on-premises API matrix currently limits inputs to PDFs and images, and leaves out cloud features including form filling, segmentation, checkpoints, thumbnails and some processing modes. Structured extraction needs the Chandra and Lift setup and supports a different set of modes.

The container also has no built-in API authentication. The documentation says the X-API-Key value is ignored. Put it on a private network behind a TLS reverse proxy that handles login and permissions. Datalab's on-premises overview puts these deployments under an Enterprise contract and commercial license, with deployment, support and offline terms negotiated separately.

Marker's license is split between code and weights

Marker's source code uses the Apache 2.0 license. Its model weights don't. The repository's MODEL_LICENSE is a modified AI Pubs OpenRAIL-M license.

The model license restricts use that isn't personal or research when the user, their employer or a related company had more than $5 million in gross revenue or total funding in the prior year. It separately restricts use in a product or service that competes with the licensor. It also has attribution and share-alike terms that reach models built from it and their output. This summary isn't legal advice. Read the actual file and talk to a lawyer before putting the weights in a commercial product.

Datalab's own pages don't agree here either. The Marker repository uses the $5 million threshold and the Apache 2.0 code license. The on-premises comparison describes the combined open-source projects as meant for startups below $2 million and sums up their licensing as "GPL + custom RAILs." For Marker, go by the license files that ship with the exact code and weights you deploy, and ask Datalab to settle any conflict in writing.

The bundled Marker server needs its own security decision. Version 2.0's server source has no authentication, accepts a file path from the caller, and builds the upload path from whatever filename it's given. Open issue #1058 and issue #1059 report that this lets someone read local files and reach paths outside the intended folder. Those demonstrations first targeted an older release, but the same patterns are still in the tagged v2 source.

Don't expose the helper server to networks you don't trust. Keep it private. If you adapt it, add authentication, keep file paths inside one folder, generate your own upload names, and add size limits, sandboxing, TLS and storage permissions that allow only what's needed.

Pros

• One service for several document jobs. Conversion, schema extraction, segmentation, form filling and versioned processors live on one platform. Checkpoints can be reused across the documented conversion, extraction and segmentation flows.
• Useful output choices. Markdown, HTML, JSON and chunks cover human-readable conversion, structured processing and search pipelines.
• A trail back to the source. Block IDs, citations and optional bounding boxes can support a review screen that links each value to its spot on the page.
• Cheap to try. The current free allowance and pay-as-you-go option let you run a realistic trial before a Team contract.
• You can run part of it yourself. Marker can keep conversion on your own infrastructure when its model license, runtime and features fit.
• The docs are open about the rough edges. Datalab publishes changelogs, rate details, gaps in the on-premises version, retention behavior and deployment caveats that buyers can check.

Cons

• Cloud, paid on-premises and Marker don't do the same things. A prototype built on one can need real changes when moved to another.
• Costs stack and can vary. Multi-step pipelines pay for each processor, and some extraction and form-filling jobs can go over the base rate.
• Official pages disagree on several details. Free credits, rate limits, bounding-box prices, webhook verification and open-source license summaries all need confirming.
• Hosted model updates can change your output. Pinning a model is generally an Enterprise feature, so regression testing becomes routine work.
• Marker's weights come with real restrictions. The Apache-licensed code doesn't make the full model stack free for commercial use.
• Running it locally costs real infrastructure. GPU inference, llama.cpp or vLLM, model downloads, job isolation, queues, monitoring and upgrades are all your job.
• User reports describe silent failures. One-off reports aren't data on how often it happens, but they make completeness checks and human review necessary for documents that matter.

Who should use Datalab

Datalab suits product and platform teams that need more than raw OCR and want to ship a document workflow without running every model themselves. Good candidates include feeding documents into search with page-level sources, pulling fields from invoices or statements with citations for review, splitting mixed document packets, filling forms, and working with tracked changes.

The hosted service is the simplest fit when you're allowed to send documents to a vendor, the per-page costs work for you, and you can get the contract terms you need. The paid on-premises product makes sense when data must stay on your own infrastructure and you can handle its GPU, proxy, authentication, monitoring and licensing requirements.

Marker is the better choice within the Datalab family for research, evaluation and local conversion, as long as its narrower features are enough and the model license allows what you're doing. It is not a free, self-hosted copy of the full Datalab platform.

Datalab is a weaker fit if you need a stable open-source interface with permissively licensed weights, a fully offline setup that runs on modest hardware, a ready-made industry processor your cloud provider already offers, or a managed human-review product. It's also a poor fit if nobody on the team owns testing, handling exceptions, watching spend and data governance.

Limitations and alternatives

The first limitation is evidence. Datalab's benchmark and speed numbers are run by Datalab, even when the benchmark comes from a third party. Open issues show what can go wrong, not how often. The only reliable way to choose is a head-to-head test, with versions pinned, on documents that look like your real ones.

Docling is a strong self-hosted alternative if you want an MIT-licensed conversion library, a structured document format and local or fully offline operation. Its repository warns that individual models have their own licenses, so you still need to check everything it depends on.

Unstructured offers an Apache-licensed library and a separate hosted API. The open-source partitioning guide describes fast, high-resolution and OCR strategies, and is upfront about trouble with reading order in multi-column pages. It's a useful comparison when you care about labeled element types and how text gets chunked later.

LlamaParse is a hosted option built around search, with several quality and cost tiers, caching controls and an Enterprise option to run in your own cloud. Its current tier guide makes it easy to compare fast text extraction with agentic parsing. The service is not the same thing as the open-source LlamaIndex SDK.

Mistral OCR is a hosted option when per-page Markdown, tables, block labels and confidence signals are what you need. OCR 4.1 is currently a public-preview commercial model, not open weights you can download, and its file-retention and annotation limits differ from Datalab's.

Google Document AI, Azure Document Intelligence and AWS Textract come first if your team already runs on that cloud, or needs a supported ready-made processor for forms, invoices, IDs, expenses or tables. They aren't straight swaps for a Markdown parser, and each feature can have its own per-page rate. For regulated work, how well they fit your identity, region, logging, key-management and private-network setup may matter more than who tops a parser leaderboard.

Whichever you test, measure missing text, invented text, reading order, how well tables and formulas survive, image coverage, how many fields come out right and how many it misses, latency, retry behavior, how often a person has to review, and the real cost per approved document. Keep at least one backup parser or a manual path for documents that fail your completeness checks.

Verdict

Datalab is a credible hosted option when you need conversion and the steps after it behind one API. Its biggest strength isn't a single OCR score. It's that you can convert, save a checkpoint, extract against versioned schemas, split packets, keep a trail back to the source and build reusable pipelines without running each model yourself.

Choose hosted Datalab when broad features and fast setup matter most. Choose paid on-premises only after confirming its narrower feature list, hardware, network controls, telemetry and contract. Choose Marker when local conversion is enough and its model license works for you. None of them replaces checks in your own code, or a person reviewing the exceptions that matter.

To start, pick a set of documents that looks like your real ones and one workflow you can measure. Test Datalab cloud against at least one other hosted option and one self-hosted option. Look for missing text as hard as you look for wrong fields, write down every processor and add-on charge, test webhooks and retries, and have security and legal review the actual deployment and license terms.

For a closer look at the open-source pieces, read Datalab in practice: Marker, Surya, Chandra and the API. To compare it with other parsers, read Extend vs Datalab vs other document parsers.

Sources

• Datalab API overview — official endpoints, request lifecycle, formats, modes, checkpoints, result expiration, and parameters; accessed August 29, 2026.
• Datalab pricing — official live plans, processor rates, variable-fee notes, EU premium, and add-ons; pricing verified August 29, 2026.
• Datalab billing — official allowances, additive billing, Team plan, rounding, and page definitions; accessed August 29, 2026.
• Datalab security — official account controls, key management, retention, training consent, network guidance, and webhook example; accessed August 29, 2026. Claims were not independently audited for this review.
• Datalab webhooks — official delivery, retry, deduplication, and shared-secret behavior; accessed August 29, 2026.
• Datalab changelog — official hosted and on-premises product changes through July 17, 2026; accessed August 29, 2026.
• Datalab version policy — official API compatibility and hosted model-update policy; accessed August 29, 2026.
• Datalab on-premises overview and API matrix — official commercial terms, deployment positioning, authentication gap, inputs, modes, and feature parity; accessed August 29, 2026.
• Marker repository and Marker 2.0.0 release — official features, installation, runtime, benchmark disclosure, breaking changes, and July 20, 2026 release.
• Marker code license and model license — official Apache 2.0 code terms and modified OpenRAIL-M weight terms; accessed August 29, 2026.
• Marker v2 server source, issue #1058, and issue #1059 — official source plus open user-reported server security concerns; issue reports are not independent audits.
• Marker issue #1066 — open challenge to the MinerU configuration in Datalab's published comparison; accessed August 29, 2026.
• Marker issue #1069 and issue #1081 — open Marker 2.0 user reports covering silent truncation and invented or omitted text; not treated as prevalence evidence.
• Ai2 olmOCR-bench — third-party benchmark framework used for Datalab's Marker run; accessed August 29, 2026.
• Docling, Unstructured, LlamaParse, and Mistral OCR 4.1 — official alternative-project and product documentation; accessed August 29, 2026.