Chunkr

Editor’s note: My Chunkr review assesses pricing, documented workflows, and migration requirements. I have not tested the product.

Quick verdict: Hosted Chunkr shuts down November 15, 2026, so I would not start a new hosted integration. Existing customers need a migration plan, while developers considering its open-source software have a separate decision to make.

Chunkr is a document parsing API for turning files into structured content for downstream applications. Its appeal is the combination of layout-aware parsing and schema-based extraction. That distinction matters: preparing passages for search is a different job from collecting invoice fields.

The hosted shutdown outweighs those features for a new buyer. I would rather spend integration time on the service that will run the eventual application, not on an intermediate dependency.

Key Takeaways

• New hosted projects should look elsewhere. Extend is the announced migration destination, not the only alternative.
• Existing customers need to preserve their documents and outputs. There is no automatic transfer to Extend.
• Parsing exposes document structure and coordinates, useful foundations for retrieval and source highlighting.
• Parse and Extract have separate credit rules. A credit should not be treated as a complete document-processing transaction.
• The open-source repository remains available, but it differs from the cloud version and lacks native Excel support.

I’ll cover the remaining hosted buying case, explain the documented workflow, and separate migration concerns from the decision to operate Chunkr independently.

Pros and Cons

I like the control exposed to developers. My concern is where that control becomes responsibility: interpreting outputs, managing processing failures, and maintaining the surrounding application remain engineering work.

How Much Does Chunkr Cost?

I treat Chunkr pricing as transition budgeting. The published plans still matter for customers keeping an existing application running during migration.

• Free ($0): 200 starting credits, without a promised monthly renewal.
• Dev ($375/month): 25,000 credits for a smaller existing workload.
• Growth ($750/month): 75,000 credits for more remaining processing.
• Scale ($2,000/month): 250,000 credits for larger existing workloads.
• Enterprise (custom): Individually priced capacity and arrangements.

Plan	Monthly price	Included credits	Overage per credit
Free	$0	200 starting credits	Not specified
Dev	$375	25,000	$0.015
Growth	$750	75,000	$0.01
Scale	$2,000	250,000	$0.008
Enterprise	Custom	Custom	Custom

For PDF, Word, PowerPoint, and images, Parse and Extract each list one credit per page. Spreadsheets use one credit per 5,000 cells for each operation. VLM-processed pages use twice the credits, excluding spreadsheets.

Illustrative calculation: 10,000 pages processed by VLM in one operation would consume 20,000 credits, or 80% of Dev’s allowance. That is not an end-to-end extraction quote.

I would budget around the application’s actual sequence of operations. A workflow that parses a source and then extracts fields should not be estimated as though only one operation occurs. The example also shows why a page count alone is an incomplete purchasing metric.

There is another cost that the pricing table cannot capture: engineering time spent supporting a dependency that is about to close. For a new project, even modest subscription savings would not persuade me to build an integration that immediately needs replacing.

Is Chunkr Good Value for Money?

• For existing customers: Temporary capacity may be worthwhile if it keeps production running while the replacement is prepared.
• For new hosted projects: I would put the budget toward a longer-term service rather than pay for an avoidable migration.
• For self-hosted developers: Software availability does not remove infrastructure expenses, model costs, or maintenance work.

I would not recommend upgrading simply because a larger allowance looks cheaper per unit. Unused capacity has little practical value, especially when the remaining workload has a fixed end date.

My recommendation is no new paid plan for a new project. For an existing application, I would buy only the bridge capacity justified by its remaining processing needs.

Getting Started With Chunkr

The documented hosted workflow starts with a choice between Parse and Extract. I would make that decision from the application’s output requirements, rather than assume extraction is always the more complete option.

Parse is the relevant starting point when the application needs document content for indexing or display. Extract is appropriate when it needs fields shaped by a schema. An invoice-processing application and a searchable policy archive may use the same source format but need very different outputs.

The dashboard documentation describes this sequence:

1. Open Tasks and select Create Task. Add the document and configure the work.
2. Submit with Process Documents. An Extract submission creates both Parse and Extract tasks.
3. Open completed task rows. The viewers expose the respective outputs for inspection.

API-key management and usage information also sit in the dashboard. I like having the operational controls near the task interface: you can inspect outputs and monitor usage in the same dashboard.

For programmatic integration, Python and TypeScript quickstarts document uploading a local file with client.files.create, then passing its returned URL to client.tasks.parse.create. URL and base64 inputs are also supported.

Submission is not completion. Processing is asynchronous: the application retains a task ID and retrieves status and output, using polling or webhooks to wait for completion. I recommend making that boundary clear in the application so that an accepted request is not mistaken for usable data.

The current SDK uses client.tasks.parse.*. Older v1 examples instead use chunkr.upload(file) and chunkr.get_task(id). My advice is to keep those interfaces separate when maintaining an existing integration; mixing examples can obscure which task lifecycle the code actually implements.

Retrieving output is only the handoff point. A source viewer needs to interpret coordinates, while a retrieval pipeline needs to decide how parsed content enters its index. Exporting valuable task outputs is also part of the remaining hosted workflow.

I recommend retaining a stable internal document identifier alongside the provider’s task identifier. That is an application-design recommendation, not a Chunkr feature. It makes provider-specific output less likely to become the only connection between a source file and the application that depends on it.

Parsing Documents Without Losing Their Structure

Chunkr’s parsing output is more useful to a developer than a single undifferentiated text string. It organizes chunks containing segments, alongside page and file metadata.

Documented representations include:

• Tables and forms: HTML.
• Text and formulas: Markdown and LaTeX, respectively.
• Pictures: Descriptions, with tabular data for charts.
• Source geometry: Pixel bounding boxes, page images, crops, and OCR word boxes.

I like this design for applications where the source must remain inspectable. A retrieved passage is more useful when the interface can show its location, rather than leave the reader searching a long PDF manually.

Still, an output field establishes a capability, not extraction accuracy. A table represented as HTML can still require application-level handling before it becomes suitable for a database or an answer-generating system.

The parsing controls are substantial. Default layout analysis can be replaced with full-page VLM processing through the Page segmentation strategy. OCR supports Auto or All, while segment handling can use Auto, LLM, or Ignore. Error handling can stop processing or continue.

These controls matter most when your document collection is inconsistent. You can treat tables differently from body text instead of forcing every element through an identical policy. The trade-off is that configuration becomes part of the application’s behavior.

Advanced settings allow each chunk to contain one segment by setting the grouping target to zero. Headers and footers can be ignored, and extended_context supplies a full-page image alongside a crop. I see those as useful controls for deciding what belongs in retrieval context, not promises of better answers.

The embed field contains text, not an embedding vector. Spreadsheet output has additional cell and range fields, but support is labeled Preview; extremely large sheets can return HTML without layout analysis.

For comparison, LlamaParse documents text, Markdown, and JSON outputs, with availability depending on tier. I would choose between these approaches around the consuming application’s needs. If a pipeline only requires readable passages, elaborate geometry may add unnecessary handling. If it needs source highlighting, throwing away layout information too early would be the more expensive mistake.

Extracting Fields With Citations and Confidence

Extract accepts a JSON Schema and either a raw document or an existing Parse task. Passing a raw file creates the parsing stage automatically; an existing parse can be reused with multiple schemas.

That separation appeals to me when several applications need different views of the same source. The document-processing step and the business-specific field definition do not have to be treated as one inseparable operation.

The documentation includes Pydantic and Zod schema-generation examples. Existing Parse tasks pass their parsing configuration and filename into extraction. I regard parsing choices as part of the extraction contract, so changing them can affect applications that reuse the results.

Extraction output separates:

• Results: The structured values.
• Citations: References associated with leaf values, including array entries.
• Metrics: Supporting extraction information.

Confidence labels are High or Low, indicating citation support rather than numerical probabilities of correctness. Citation creation can also be Created, Failed, or Skipped. References may include document coordinates or spreadsheet ranges; word-level citations are optional.

I see those signals as review aids, not approval to accept a value automatically. A cited value can still be unsuitable for a business action if its meaning has been misunderstood. An invoice date and a payment due date, for example, can both be clearly printed while serving very different purposes.

Consider an illustrative invoice schema asking for supplier name, invoice number, and total. I would keep the original labels and evidence accessible when presenting those fields for approval. This is a design example, not a reported Chunkr result.

For financially consequential data, returning a value is only the first step. Citation support cannot decide whether a supplier is approved or whether a total matches the expected purchase.

Extend becomes relevant here because its documented scope includes extraction and chained workflows as well as parsing. I would consider it when the goal extends beyond returning structured fields into coordinating subsequent document-processing steps. That is a scope distinction, not evidence that either product extracts more accurately.

Self-Hosting, Security, and Operational Limits

Self-hosted Chunkr is a separate product decision. It does not reproduce the hosted service unchanged. The repository uses open or community models, while the hosted API uses proprietary in-house models.

The repository’s deployment options include:

• Docker Compose configurations: GPU, CPU-only, and Mac ARM.
• Model connections: An OpenAI-compatible endpoint, with provider and fallback configuration.
• Licensing: AGPL-3.0 or a commercial license for the core.

Native Excel support is excluded from the open-source feature matrix. I would not move a spreadsheet-dependent application to that build on the assumption that the familiar product name implies equivalent functionality.

The repository remains available under its existing license. That preserves an option, not a guarantee about future maintenance. I recommend self-hosting only when owning the deployment is already part of your engineering strategy.

Commercial on-prem documentation separately lists an eight-core CPU, 16 GB RAM, and 1 TB SSD minimum, with optional GPU and volume-dependent sizing. Those are commercial on-prem specifications, not universal requirements for every community installation.

Hosted operations also have limits. Tasks time out one hour after processing starts, and the documented request limit is 10 files per second. Documents have a 2,000-page soft limit; base64 requests have a 1 GB total-request ceiling. Larger documents can fail, so I would not describe capacity as unlimited.

Retention deserves equal attention. Task data remains unless expires_in is configured; the documentation illustrates automatic cleanup after 24 hours. Minimal billing and audit metadata can remain. Configurable expiration is not zero retention.

The detailed security policy limits its no-model-training promise to Scale and above. It describes SOC 2 Type I and II audits as ongoing, rather than establishing completed certification. I would not extend those statements into a blanket compliance endorsement.

For a local-first alternative, Unstructured’s open-source library covers partitioning, cleaning, and chunking. Its core library does not include managed scheduling or built-in embedding generation. I see both local approaches as infrastructure choices: removing a hosted dependency also means taking responsibility for more of the system.

Moving From Chunkr to Extend

Moving from Chunkr to Extend is an application change, not an API-key replacement. Extend requires a separate account and key, and existing documents and task outputs do not transfer automatically.

My priority during the move is preserving application behavior:

1. Preserve the source material and outputs. Export the required Chunkr data and retain source files for re-upload.
2. Map the application’s data contract. Chunkr tasks become Extend runs, segments become blocks, and extraction results move to value.
3. Adapt downstream consumers. Update the code that builds retrieval context, displays evidence, and handles cleanup.

The output changes deserve more attention than the names alone suggest. A successful API response says little about whether an existing viewer highlights the right place or whether an index receives comparable passages.

Extend uses character-based chunking, rather than Chunkr’s token-based approach. I would not copy a chunk-length setting numerically and assume it represents the same amount of text. Chunk boundaries affect what the retrieval system can return together.

Bounding-box conventions differ too. Chunkr uses pixels and left/top/width/height; Extend uses points and left/top/right/bottom. Normalizing either response to page fractions is a separate application step. Your viewer needs to account for both the units and the changed box shape.

The migration mapping also lacks direct equivalents for some Chunkr features, including extended_context and certain spreadsheet citation fields. That does not establish that Extend has no related capabilities; it means those dependencies need a different design.

Cleanup is another behavior change. The migration guide describes no per-run expiration parameter in Extend and instead uses deletion of runs and files after results are retrieved. Parse and file download presigned URLs expire after 15 minutes.

The application must distinguish download-link expiry from data deletion. A link becoming unusable does not, by itself, establish that its underlying data has been removed.

My strongest migration recommendation is to protect the application’s internal contract. Keeping provider-specific structures behind an adapter can make this transition more contained and reduce the cost of another provider change later.

How Does Chunkr Compare to Alternatives?

I shortlist alternatives by deployment and workflow. The right alternative depends on whether the application needs managed parsing, broader document automation, or local processing.

• Extend: My first comparison for existing hosted customers because it is the announced destination. Its scope includes classification, splitting, and editing alongside parsing and extraction. Migration still requires conversion work.
• LlamaParse: My managed-parsing shortlist option for new projects. Output selection matters: its Fast tier returns text or spatial text, not Markdown.
• Unstructured: My alternative for developers prioritizing local partitioning or ingestion pipelines. Its open-source library, Ingest tooling, and managed service should be evaluated separately.

Option	Deployment focus	Relevant scope	Main buying caveat
Chunkr hosted	Managed API	Parsing and extraction	Shuts down November 15, 2026
Chunkr open source	Self-hosted	Configurable document processing	Different models; no native Excel
Extend	Managed platform	Parsing and document workflows	Output and lifecycle conversion
LlamaParse	Managed parsing	Tier-dependent document outputs	Output capabilities vary by tier
Unstructured	Local library and separate managed tools	Partitioning and ingestion	Local and hosted capabilities differ

This shortlist is not a quality ranking. Published output options cannot establish which service handles a particular collection most accurately.

For a new buyer, my default would be to compare Extend and LlamaParse directly for managed processing. I would bring Unstructured into the decision when local control or the wider ingestion pipeline matters more than keeping the application’s infrastructure footprint small.

How I Reviewed Chunkr

I evaluated Chunkr’s documented pricing units, interfaces, output structures, and deployment options. I also considered how its shutdown and migration requirements change the buying decision for new and existing customers.

My recommendations distinguish specifications from outcomes: configurable processing is not measured accuracy, and published security language is not an independent audit conclusion. This is a documentation-based assessment, not a performance comparison.

Prices are current as of October 2026. I give the hosted service’s remaining lifespan more weight than feature breadth because it directly affects whether an integration is worth building.

Should You Choose Chunkr?

I would skip Chunkr for a new hosted project. Building directly against an alternative is the more sensible use of development time when the service has an announced closing date.

For an existing hosted customer, I would focus spending on continuity and engineering on migration. Preserving source files and usable outputs matters more now than adopting additional Chunkr-specific behavior.

I would consider open-source Chunkr only as an independent infrastructure choice. A developer willing to operate models and maintain the surrounding services may still find it relevant, but that decision should stand on its own merits.

The hosted service is ending, while the self-hosted software remains available. My recommendation is to choose the destination first, then spend only the effort needed to get the existing application there safely.

Frequently Asked Questions

Is Chunkr shutting down?

Hosted Chunkr remains live through November 14, 2026, and shuts down November 15, 2026, following its acquisition by Extend. The open-source repository remains available. I would distinguish hosted-service migration from self-hosted operation.

Does Chunkr offer free credits?

Chunkr lists 200 starting credits, not a promised monthly renewal. I see that as a limited starting allocation rather than ongoing production capacity.

Is open-source Chunkr the same as the cloud version?

No. The builds use different models, and the open-source feature matrix excludes native Excel support. I would not assume identical outputs or cloud feature parity when choosing self-hosting.

Can Chunkr replace a complete RAG application?

No. Chunkr prepares document content, but its embed field is text rather than a vector. Embedding generation and the retrieval layer remain separate responsibilities. I would choose it as a processing component, not as a complete question-answering application.