Marker (Datalab)

Editor’s note: This review is independent analysis of documented workflows, pricing, and licensing, not a measurement of output accuracy.

Quick verdict: I recommend Marker for developers who want local document conversion and can manage its dependencies and model-license conditions. I recommend Datalab Cloud for managed parsing and schema extraction, but it is a different product, with separately metered operations.

The distinction drives this Marker review: the local Marker library converts documents, while Datalab’s hosted platform runs a Chandra-based service. A cloud subscription is not simply the same package running on someone else’s server.

For a data team comparing document parsing tools, that matters more than the shared branding. Deployment control points toward local Marker. Extracting invoice fields into a defined schema points toward Datalab Cloud. Neither choice removes the need to validate documents before they reach a production system.

Key Takeaways

• Local conversion: Marker exports Markdown, HTML, JSON, and chunks for downstream processing.
• Managed field extraction: Datalab Cloud supports user-defined schemas and source citations in selected modes.
• Low-commitment entry: Hosted Free includes a recurring monthly usage allowance without requiring a card.
• License caveat: Apache 2.0 covers the code, but separate model terms restrict some commercial and competitive uses.
• Cost caveat: Per-request rounding and separately billed processors can increase costs beyond the headline conversion rate.

I’ll cover the costs first, then the setup and three buying decisions: conversion outputs, structured extraction, and deployment control. I’ll also explain when I would shortlist Docling, LlamaParse, or Unstructured instead.

Marker Pros and Cons

Local control is Marker’s strongest appeal. My main reservations are the model-license restrictions and the engineering work required to run it.

I like the deployment options, but I would not treat them as interchangeable. Moving from local conversion to hosted extraction changes both the application workflow and the cost model.

How Much Does Marker (Datalab) Cost?

Local software can cost $0, within the model-license terms. Hosted Datalab combines monthly allowances with metered processing, so the useful comparison is infrastructure ownership versus a processing bill.

• Local Marker: $0 software, within the applicable model terms, for developers supplying their own infrastructure.
• Free: $0/month, with $20 monthly usage for work-email accounts or $10 for personal-email accounts, for initial evaluation.
• Pay-as-you-go: usage-based, enabled by adding a card, for workloads that do not need a subscription commitment.
• Team: $400/month, including $400 monthly usage, for organizations needing team controls and contractual data provisions.
• Enterprise: custom pricing, for private deployment and enterprise requirements.

Route	Fixed price	Included usage	Main consideration
Local Marker	$0 software within model terms	No hosted allowance	Infrastructure and engineering costs remain
Free	$0/month	$20/month with work email; $10 with personal email	No card required for allowance
Pay-as-you-go	No subscription or minimum spend	Recurring allowance subject to account terms	Metered processing after allowance
Team	$400/month	$400/month	Same processor rates; BAA/DPA and enforced team MFA
Enterprise	Custom	Contract-dependent	VPC or air-gapped deployment, SSO, custom MSA/SLA

The Free allowance resets every 30 days. I would use it for a recurring evaluation budget and price a large backfill separately.

Hosted conversion costs $4 per 1,000 pages in fast or balanced mode and $10 per 1,000 pages in accurate mode. Those rates cover conversion alone. Extraction, coordinate add-ons, and cross-page merging can increase the bill.

The easily missed detail is per-request cent rounding. Each API request’s charge rounds up to the nearest cent, so document size and request structure affect effective page cost.

For example, a one-page fast conversion has a nominal charge of $0.004, rounded to $0.01. In this hypothetical workload, one thousand separate requests would total $10 before credits or discounts, rather than $4.

Extraction is separately metered, and parsing costs extra when it runs. Complex balanced or accurate extraction can use compute-based billing, taking the higher of the page-based and compute-based amounts. I would budget for the selected workflow rather than multiply every page by the conversion rate.

For REST integrations, extraction_mode and parsing mode are separate settings. Balanced extraction defaults to accurate parsing when the parsing mode is omitted. I would set both explicitly, then use the completed response’s cost_breakdown to track charges for that configuration. This matters when the same document goes through several processors or a large schema increases processing work.

Optional processing also changes the calculation. Cross-page merging is a beta feature with variable compute charges. EU processing adds 25%, while a 25% retention discount requires opting into data retention for model improvement. I would make that data decision before considering the saving.

Is Marker (Datalab) Good Value for Money?

My value judgment depends on what the purchase replaces:

• Choose local for control: Existing infrastructure and engineering capacity can make local conversion attractive, provided the model terms fit.
• Choose pay-as-you-go for flexibility: Avoiding a monthly commitment suits intermittent workloads and pilots.
• Choose Team for governance: Its included usage does not come with a lower processor rate. The justification is its team controls and BAA/DPA provisions.

Local is not automatically cheaper once maintenance and hardware enter the calculation. Equally, I would not buy Team solely because a project has moved beyond experimentation.

Reviewer’s Notes: For a developer evaluating hosted parsing, I recommend starting with Free and representative documents. Move to pay-as-you-go when the allowance becomes restrictive; choose Team when its administrative or contractual features solve a specific requirement.

Getting Started With Marker (Datalab)

Choose the deployment route first. A browser-based Datalab evaluation will not establish how local Marker behaves on your hardware, because the hosted implementation differs.

Setting Up Local Marker

Local Marker requires Python 3.10 or later and PyTorch. I would budget for configuring an inference backend as well as installing the package.

The local setup involves five steps:

1. Check the licenses: Review both the Apache code license and the separate model terms before incorporating Marker into a product.
2. Install the package: Use marker-pdf, or marker-pdf[full] when the additional file-format dependencies are needed.
3. Configure inference: Install the required backend, vLLM on NVIDIA GPUs or llama.cpp for CPU or Apple Silicon. Marker can start its local server on first use.
4. Convert a representative file: Use marker_single with an explicit output format.
5. Inspect the result: Compare the converted structure with the original before connecting it to downstream automation.

An optional Streamlit interface launches through marker_gui. That offers another entry point, but it does not remove the underlying inference requirements.

Defaults deserve attention: local mode defaults are balanced on GPU and fast on CPU/MPS. I would set the mode explicitly in an evaluation so a hardware change does not silently change the processing configuration.

Fast mode on a clean digital file without equations can avoid starting the vision-language model server. Disabling OCR also disables VLM calls, but skips scanned-page and equation OCR. I would not use that switch as a general shortcut for a mixed document archive.

Starting With Datalab Cloud

Forge provides a browser upload interface for trial conversions and a visual schema editor. I would begin there to decide what the application needs before writing integration code.

For the API route:

1. Review account data settings: Decide whether any retention opt-in fits the documents being processed.
2. Create an API key: Use the API Keys dashboard for code integration.
3. Install the SDK: datalab-python-sdk uses DatalabClient and the DATALAB_API_KEY environment variable.
4. Select mode and output: Make both explicit. For extraction, set extraction_mode separately from mode, which controls parsing.
5. Handle completion and storage: Save successful outputs in your own system before hosted results expire.

The SDK’s client.convert handles polling. REST integrations submit a job and poll the returned request_check_url.

My main integration warning is complete does not mean successful. A finished conversion can return status=complete with success=false; the application needs to inspect both. New integrations should also use the current operation-specific API rather than the deprecated combined Marker endpoint.

Converting PDFs Into Useful RAG Content

Marker is an ingestion component, not a complete retrieval-augmented generation application. I would shortlist it when the missing piece is converting documents into content that another system can index.

The output choice should follow the downstream task:

• Markdown: My starting choice for readable text with document structure that can be inspected directly.
• HTML: Useful when a consuming application needs explicit markup and supported coordinate information.
• JSON: Appropriate for code that needs document blocks, block types, and bounding boxes.
• Chunks: An export intended for downstream search or embedding workflows.

For a Marker PDF to Markdown workflow, I value the ability to preserve headings and content boundaries for downstream code. A policy manual, for example, needs its exceptions associated with the right policy. Splitting that text into chunks without its heading can remove context that a retrieval system needs.

I would favor HTML or JSON for financial and research documents where layout needs explicit representation. A readable Markdown preview is not sufficient evidence that a table’s values remain associated with the correct headers.

The practical inspection criteria are:

• Reading order: Does a multi-column page become a coherent sequence?
• Table structure: Do values retain their relationships to row and column labels?
• OCR coverage: Are scanned regions represented rather than omitted?
• Source traceability: Can the application connect important content back to its document location?

Datalab Cloud offers fast, balanced, and accurate conversion modes. I would compare them against the same acceptance criteria rather than assume that the highest-priced mode is necessary for every document.

Hosted cross-page merging can address tables, paragraphs, and lists that continue across page breaks. Its beta status and variable charges make it a deliberate workflow choice, not something I would enable indiscriminately.

After conversion, the RAG system still needs embedding, storage, retrieval, and answer evaluation. Chunk export does not settle those design decisions.

Docling is a relevant local alternative here because it also provides chunking and structured exports, alongside framework integrations. I would compare integration effort and output suitability, not assume that either parser wins across every document type.

Structured Extraction Belongs to Datalab Cloud

JSON conversion is not schema extraction. A document tree describes content and layout; a business schema asks for specific fields such as an invoice number or payment total.

Marker 2 removed its old structured-extraction converter. I would therefore choose Datalab Cloud, or build a separate extraction layer, when the requirement is to fill a defined schema.

Forge’s visual schema editor provides a starting point. For an invoice workflow, I would define precise field types and descriptions, then inspect extracted values alongside their source references before importing them into another system.

Mode selection changes what the application receives:

• Fast, balanced, and accurate: Support source citations.
• Turbo: Returns extracted JSON without OCR output, citations, verification, or confidence scoring.
• Balanced and accurate: Can include extraction status, reasoning, and verification metadata.
• Cloud fast extraction: Supports asynchronous numeric confidence scores, which can fail separately from extraction.

I would avoid turbo for workflows requiring citations. Its missing review metadata matters if someone must trace a disputed total back to its source.

Balanced and accurate modes accept up to 750 scalar schema fields. Fields inside objects and arrays count, but repeated array items do not multiply the schema count. That is a schema-design constraint, not a promise about list completeness.

Verification is also not a correctness guarantee. A missing verification result is not a pass, and unresolved fields or incomplete lists need application-side handling.

Checkpoints are a useful cost-control feature: saved conversion state can be reused for extraction without re-parsing. Extraction charges still apply, and turbo cannot reuse checkpoints.

For repeatable production processing, I like the availability of immutable published pipeline versions. Pinning a version separates a stable integration from subsequent draft edits.

LlamaParse belongs on the shortlist if extraction is part of a broader managed parsing and indexing requirement. My preference would depend on how much of that surrounding workflow the application needs.

Hosting, Privacy, and the License Catch

Local execution and unrestricted use are different things. Marker gives developers a local deployment option, but the model weights do not inherit the code’s Apache 2.0 license.

The weights use a modified AI Pubs Open RAIL-M license. Its commercial restrictions apply above either $5 million in prior-year gross revenue or $5 million in total equity or debt funding, with research and personal-use exceptions. Competitive products and services face separate restrictions.

I would review those terms before implementation, especially for a competing service. Being below a financial threshold does not remove the separate competitive-use restrictions.

Local operation also transfers ongoing responsibility to the buyer:

• Infrastructure: Provision and maintain the inference environment.
• Access control: Protect documents and processing endpoints.
• Storage: Manage original files and generated outputs.
• Updates: Decide when dependency and model changes enter production.

Datalab’s paid on-prem deployment is a separate Enterprise arrangement, not another name for installing Marker. I would assess its contracted capabilities independently rather than assume local, hosted, and on-prem feature parity.

One operational detail deserves emphasis: the on-prem container does not require API-key authentication by default. Access control must be supplied at the network or proxy layer. Private placement alone is not an authentication policy.

For hosted processing, conversion results expire after about one day and can be deleted earlier. Plan to save outputs in your own storage; other platform data and retention settings need separate consideration.

Training and model-improvement consent is opt-in through team settings. I would keep that choice separate from routine purchasing decisions, especially for customer documents.

Account controls also have boundaries. TOTP is available on all accounts, and Team administrators can enforce enrollment, but that policy does not affect API-key authentication. Per-key spending limits provide a separate budget control.

My recommendation is local Marker when infrastructure ownership is the requirement and the license fits. For supported private deployment or contractual commitments, I would evaluate Enterprise rather than stretch the free package into an equivalent offering.

How Does Marker Compare to Alternatives?

Docling is my first local alternative; LlamaParse and Unstructured belong in a comparison of managed workflows. The right shortlist depends on which parts of document processing you want to operate yourself.

• Docling: My first alternative for a local-toolkit evaluation. It offers local and air-gapped execution, multiple OCR engines, and chunking, plus integrations with frameworks including LangChain and LlamaIndex. Its code is MIT licensed, but component and model licenses still need separate attention. I would favor it for evaluation when framework compatibility matters more than staying within Datalab’s ecosystem.

• LlamaParse: My managed alternative when parsing, extraction, and indexing belong in the same purchasing decision. Its credit model varies by operation, so credits are not interchangeable with pages. I would compare the full intended workflow with Datalab, including indexing needs, rather than compare headline allowances alone. Commercial LlamaParse is also distinct from the open-source LiteParse project.

• Unstructured: My alternative when document ingestion also needs connectors, embedding generation, and scheduling. Those platform features can matter more than the conversion endpoint itself. I would not compare its broader pipeline price directly with Datalab’s conversion-only rate, because that would ignore part of the work being purchased.

I would keep Marker on the shortlist for local conversion, and Datalab for managed extraction with source references. Neither automatically replaces the surrounding pipeline offered by a broader platform.

How I Reviewed Marker (Datalab)

I evaluated Marker and Datalab as separate buying options, using their documented workflows, pricing, and deployment terms. My recommendations weigh implementation responsibility against the capabilities a developer or data team receives.

The cost analysis uses published rates, per-request rounding, and additive processing charges. Its example workloads are hypothetical. I did not run parsing benchmarks or measure support responsiveness; the recommendations concern product fit and documented trade-offs.

Prices are current as of October 2026.

Should You Use Marker (Datalab)?

I recommend local Marker for developer-led conversion on infrastructure you control, provided you can accept the operational work and model-license conditions.

I recommend Datalab Cloud instead when the requirement is managed parsing or schema-based extraction. Its citations and extraction metadata give an application material for review, but they do not replace validation rules.

I would skip local Marker if the expectation is a ready-made invoice extraction service. I would also look beyond conversion alone if the project needs scheduled ingestion and connectors, with Unstructured as a relevant alternative. Docling deserves a parallel evaluation for local framework integration.

My concrete starting recommendation is Datalab Free for a hosted pilot. Use a representative document set and define acceptance criteria before paying for additional volume. For a local deployment, settle the model-license question first.

Frequently Asked Questions

Is Marker free?

The local software can cost $0 within the model terms, but infrastructure is your responsibility. Apache 2.0 covers the code, while the model weights have separate restrictions. Hosted Datalab has recurring free allowances and metered paid usage.

Is Datalab Cloud the same as Marker?

No. Marker is a locally runnable conversion package. Datalab Cloud runs a Chandra-based hosted service with separate capabilities and pricing. I would not use a cloud evaluation as evidence of local Marker behavior.

Can Marker run on a CPU?

Yes. The documented inference options include llama.cpp for CPU and Apple Silicon. CPU/MPS defaults to fast mode; GPU defaults to balanced. Set the mode explicitly when comparing configurations.

Is Marker a complete RAG system?

No. It produces ingestion outputs. Embedding, storage, retrieval, and answer evaluation remain downstream responsibilities.

Does JSON output extract invoice fields?

Not by itself. Conversion JSON represents document content and structure. Filling a defined invoice schema requires Datalab’s extraction service or a separate extraction workflow; Marker 2 removed its old extraction converter.