What Marker exposes
Marker's current repository supports PDFs, images, Office formats, HTML, and EPUB, with configurable fast and balanced modes. It reconstructs tables and equations, extracts images, can disable OCR for a text-layer path, and can use an LLM for correction and complex structures.
This makes Marker a specific processing layer, while DocParse is evaluated here as the application-facing ingest and normalization boundary around one or more parser routes.
- Marker outputs Markdown, JSON, HTML, or chunks and exposes Python and CLI integrations.
- Fast, balanced, forced-OCR, no-OCR, and optional LLM modes create several accuracy, latency, and infrastructure trade-offs.
- The code is Apache-2.0, while the repository documents separate terms for model weights and larger commercial use.
Choose Marker when its native layer is the product fit
Choose Marker when its documented output, deployment model, and surrounding ecosystem align with the application. Do not add an orchestration layer merely to make the architecture look provider neutral.
Confirm the exact region, API version, quota, retention behavior, and commercial terms for the account before production; those properties change independently from parser accuracy.
- Self-hosting, source access, parser customization, and local processing are core requirements.
- The team can provision and operate Python, model weights, inference backends, GPU or CPU capacity, queues, monitoring, and upgrades.
- The current code and model licenses have been reviewed for the organization's exact commercial deployment.
Choose DocParse when the ingest boundary must stay stable
DocParse is useful when callers should not know which format-specific parser, deterministic container, OCR service, or approved model handled a file. The manifest exposes the route for audit and evaluation while the application consumes the same Markdown and DocIR shapes.
That abstraction has a cost: it is another service boundary. It is justified only when normalization, multi-format routing, tenant operations, or provider control removes more application complexity than it adds.
- You want an HTTP API and product controls without running parser or inference infrastructure.
- Multiple routes must produce the same DocIR, manifest, lifecycle, and Markdown contract for downstream systems.
- Tenant admission, keys, quotas, webhooks, usage accounting, provider policy, and purge are part of the requirement.
Run a representative bake-off before migration
Freeze a fixture set that reflects production frequency and difficulty. Send identical source bytes, pin documented options and versions, and score whether the result is accepted by chunking, retrieval, extraction, review, or automation—not whether a demo page looks clean.
Report outcomes by document class and include retries, human review, storage, provider calls, orchestration, and engineering ownership in total cost. A winner on clean reports may lose on degraded scans or on operational fit.
- Local infrastructure cost
- Digital and scanned modes
- Tables and equations
- License review
- API and job operations
- Upgrade and model governance
Frequently asked questions
Questions teams ask before building
Is DocParse more accurate than Marker?
This page does not claim universal accuracy. Accuracy depends on document class, configuration, model or parser version, and the downstream acceptance rule. Run both on a frozen representative corpus.
Can DocParse replace every Marker feature?
No. DocParse focuses on parsing, normalization, routing, and lifecycle controls. Specialized extraction, workflow, ecosystem, or deployment functions documented by Marker may remain outside its scope.
What should a production evaluation measure?
Measure structural acceptance, table and reading-order correctness, citation traceability, latency distribution, retries, provider and review cost, operational effort, security constraints, and migration compatibility.