Anything to Markdown. PDF, DOCX, PPTX, XLSX or a URL in — clean, structured, model-ready text out.
Drop it.
PDF · DOCX · PPTX · XLSX · XLS · HTML · CSV · MD
Drag anywhere in the frame, or O
Free · one conversion a day, no account. Today’s is still yours.
WHERE IT RUNS
This page converts one document at a time so you can see exactly what the engine does with yours. An estate is not converted through a browser: it is converted by the same engine, running inside your own network, across as many cores as you point at it.
The Python engine on your own servers. Nothing is uploaded, and the output is deterministic — same bytes in, same Markdown out.
A crunch tool inside your agent loop, on stdio or streamable HTTP. The agent converts a document before it reads it, so the raw file never enters the context window.
POST /v1/crunch. One synchronous call, Markdown and a structure map back. Same engine, same numbers as the panel above.
The demonstration. Drop one document and watch the engine work on it, with the real measurements from the real conversion.
On the CLI and the MCP server: both are finished and both run on your own machines. They are not on PyPI or npm yet, and we would rather say that than print a command that 404s on the first thing you try. Publishing them is the open-source release — until it lands, the API above is the same engine with the same numbers, and an evaluation of the local build is a conversation rather than a download.
Conversion is CPU-bound and parallel across documents, so the honest unit is a page per core and you multiply by the cores you have. There is no GPU in this path — a DGX-class box converts an estate with its accelerators idle, and a plain 128-core server does it just as fast.
The 86× between them is the document, not the machine — tables, columns and figures are the expensive part, and a page of plain prose is nearly free.
| Cores | Text-layer pages/hour | Dense pages/hour |
|---|---|---|
| 8 | 4,800,000 | 56,140 |
| 32 | 19,200,000 | 224,561 |
| 128 | 76,800,000 | 898,246 |
10M pages · one 32-core server · one weekend
44.5 hours at the worst case this engine has: every page dense-class, tables and columns all the way through. A real estate is mostly text-layer, so the same job is an overnight run. A million pages finishes in under five hours on the same server even if every page is dense.
crunch.md per page, per core · median of 3 runs · conversion is CPU-bound and parallel across documents, so it scales with cores and uses no GPU · read 2026-09-07
THE CASE
The same documents, in a form a model can read without paying to look at a picture of them — and, for most of what is on a SharePoint, in the only form a model will take at all. Five claims below, each with the number it rests on and where that number came from.
01 · RESIDENCY
Verified in the source rather than asserted in a policy document: across the whole engine, the only module that opens a socket is the URL fetcher you explicitly hand a URL to. PDF, DOCX, PPTX and XLSX extraction, normalisation and Markdown emission make zero network calls. Run it inside your perimeter and conversion costs you nothing but your own compute.
| Path | Egress | Default |
|---|---|---|
| Every text-layer format — PDF, DOCX, PPTX, XLSX, HTML | None | On |
| Local OCR (Tesseract) | None | Available |
| Azure container (read-4.0), self-hosted | Your private network | Opt-in |
| Azure, Google or Mistral cloud OCR | Third party | Refused unless enabled |
The engine runs entirely inside your network — every format, including scanned pages, because the OCR engine is local too. Cloud OCR is available if you want it, off by default, and the conversion tells you which pages used it.
crunch.md verified in the source, not asserted · the only module that opens a socket is the explicit URL fetcher, which re-checks for SSRF on every redirect hop · read 2026-09-07
OCR ships with a local engine — Tesseract, with seven languages installed: Hungarian, German, English, Polish, Romanian, Czech, Slovak. It reads page rasters on your own CPU and sends nothing anywhere. An enterprise with its own trained language data points the engine at that instead.
Azure, Google, Mistral and an engine you already run yourself all plug in behind one provider protocol, and a provider must declare its egress to be selectable at all. The policy defaults to local-only, so a cloud call is refused at the door rather than audited afterwards.
Whichever engine ran is recorded on the conversion, in the structure map and in a warning written for a person — so an operator in a regulated environment can prove where a page was read, instead of citing a policy. The optional remote token counter is separately gated behind a flag and a credential, and is off unless you switch it on.
The engine fails loudly, per page, and never invents text for a page it could not read. Point it at your estate. It converts everything with a text layer and tells you precisely which pages don’t have one. That is a survey of your estate, from your estate, before anyone commits to an OCR budget.
02 · THE FORMATS WITH NO NATIVE PATH
Anthropic's Files API does not accept DOCX, PPTX or XLSX as document blocks. Its own documentation says to convert them to plain text first. So for the majority of what sits on a twenty-year SharePoint, conversion is not an optimisation you might take — it is mandatory, and the only question left is whether the structure survives it.
Converted badly, they arrive as a wall of words with the grid taken out. Converted well, the deck keeps its slide titles, the workbook keeps its sheets and its headers, and the specification keeps its numbering.
Anthropic Files API — DOCX, PPTX and XLSX are not accepted as document blocks; the documentation says to convert them to plain text source ↗ · read 2026-09-07
| Window | Models | Native | Crunched | Only works crunched |
|---|---|---|---|---|
| 1M | Fable 5.1, Opus 5, Sonnet 5 | 468 pp | 1,315 pp | 469–1,315 pages |
| 200K | Haiku 4.5 | 93 pp | 263 pp | 94–263 pages |
crunch.md measured over 16 real PDFs, 152 pages, exact tiktoken o200k_base counts · reproduce with ‘crunch bench’ · read 2026-09-07
Anthropic PDF limits — 600 pages a request (100 below a 1M window), 32 MB a request; long context carries no per-token price premium source ↗ · read 2026-09-07
600 pages a request, and 100 below a 1M window. A native PDF hits that limit whatever its token count. Markdown is text: it has no page limit at all.
A dense PDF can exhaust the context window before it ever reaches the page limit, which is why a binder that "should fit" does not. The Markdown of the same binder is a fraction of the bytes.
A 900k-token request costs the same per token as a 9k one, so this is a capacity argument rather than a pricing one: what the window decides is how much of your document the model can hold at once. §03 is where the price comes in.
03 · TOKENS
Send Claude a PDF and it charges you for the text it pulls out and for a rendered image of the page. Markdown drops the image. Same words, same headings, same tables — one bill instead of two, on every page, on every pass.
64% fewer input tokens a page — 1,374 tokens a page that stop being billed.
Against what, exactly. A native document upload on Claude — Fable 5.1, Opus 5, Sonnet 5 — where a PDF page is charged as a page image plus its extracted text. That is the comparison every figure on this page is stated against.
crunch.md measured over 16 real PDFs, 152 pages, exact tiktoken o200k_base counts · reproduce with ‘crunch bench’ · read 2026-09-07
Anthropic PDF support — the system converts each page into an image, and extracts the text alongside it source ↗ · read 2026-09-07
Anthropic vision — a page image is billed in 28×28 pixel patches, capped at 1,568 visual tokens on the standard tier source ↗ · read 2026-09-07
Google bills a PDF page at a flat 258 tokens and Gemini 3 does not separately charge for the text it extracts, so our Markdown costs about 2.9× more there. Route by model: crunch for Claude, upload natively for Gemini. On Gemini what crunch.md buys you is structure, and §05 is where that argument lives.
Google document processing — each PDF page counts as a flat 258 tokens, and Gemini 3 does not separately charge for the text it extracts source ↗ · read 2026-09-07
It is the cap on the standard visual tier. Opus 5 renders pages at the higher-resolution tier, where the same page image is worth more — but that depends on a render resolution Anthropic does not publish, so we bill the comparison at the smaller figure. Anthropic's own worked example implies about 2,333 tokens a page, which is above the 2,134 we quote. The real saving is larger than the bar shows.
Pipes, hashes and dashes cost 1.34× a bare text dump — 760 tokens against 566. That third is the whole point: it is the grid, the heading tree and the numbering, and it is what turns an extraction into something a model can navigate.
04 · MONEY
Input tokens only, at published list prices, on the model you pick. The multiplication is printed underneath so you can check it — and it is the cost of reading the corpus once.
List price for input tokens, standard rates. Output is the same either way, so it is not counted here.
YOU KEEP $6,870 on every pass
Anthropic published list prices, input tokens, standard (non-batch) rates · a snapshot, they move source ↗ · read 2026-09-07
crunch.md measured over 16 real PDFs, 152 pages, exact tiktoken o200k_base counts · reproduce with ‘crunch bench’ · read 2026-09-07
AND A CORPUS IS NOT READ ONCE
Every re-index, every model change, every evaluation run reads the corpus again, and the saving lands again with it. We publish no multiplier — there is no honest figure for how often your estate is re-read — so the number above is one pass and the multiplication is yours.
A batch API halves the native column, the crunched column and the saving alike. The ratio between them does not move, so the figure above holds at either rate.
It scales both columns proportionally rather than closing the distance between them, and its lifetime is minutes to an hour — so a corpus re-read days apart never hits it at all.
Bulk vector indexing is the exception: an embedding pass takes text only, with no page image, so Markdown costs more there than a plain extraction. Index from the text, read from the Markdown. And on Gemini the ledger runs the other way: a million-page pass costs about $1,004 more crunched than native. Route by model.
05 · STRUCTURE
Fewer tokens is the argument people check. This is the one that decides whether the answer is right. Headings, tables, lists and footnotes come through as headings, tables, lists and footnotes — so a chunk stays citable, a number stays attached to its row, and an answer can be traced back to the place it came from.
Tenor EUR USD GBP 1 year 3.10 4.45 4.20 5 year 3.75 4.60 4.35 10 year 4.05 4.72 4.48
| Tenor | EUR | USD | GBP | | ------- | ---- | ---- | ---- | | 1 year | 3.10 | 4.45 | 4.20 | | 5 year | 3.75 | 4.60 | 4.35 | | 10 year | 4.05 | 4.72 | 4.48 |
Illustration — the same rows, formatted two ways. Not a measurement.
This is the argument that holds on every model, at every price, including the ones where the token count runs against us. A rate, a dose or a tolerance that has come loose from its row is not a formatting problem — it is a wrong answer with a citation attached.
HOW WE MEASURED
16 real multi-page PDFs — technical specs, a strategy deck, brochures, a table-heavy
pricing matrix, one-pagers — 152 pages in total, run through crunch-core with exact tiktoken o200k_base counts rather than a heuristic. Mean 566 tokens of extracted text
a page in, 760 tokens of Markdown out. Speed is stated per page
per core — 6 ms for a text-layer report, 513
ms for a dense design-heavy one, a 86× spread that belongs to the document rather than
the machine. Run the whole thing yourself: crunch bench.
Every figure on this page is either ours and reproducible with that command, or a named vendor's with the URL and the date we read it. Prices are a snapshot and they move; the date under each one is when we last checked it. Last checked 2026-09-07.
WHO THIS IS FOR
A token count is abstract until it is your document. Pick the desk you recognise. The panel says what arrives, what it costs to hand a model the file as it is, which part of the structure a plain text dump destroys, which surface fits the workflow — and the one thing crunch.md will not do for you on that desk.
A 180-page share purchase agreement: ninety pages of operative clauses numbered four levels deep, sixty pages of schedules, and a scanned execution bundle at the back.
Hand the file over as it is and the context window is largely spent before anyone asks a question about clause 8.2.1. One matter holds dozens of these.
8.2.1 stays nested under 8.2, under 8. Defined terms keep their capitals, schedules stay tables. Flatten it and a model can still quote clause 8.2.1 — it just can no longer tell you what that clause hangs off, which is usually the answer.
Drop one agreement on this page to see what comes back. Call POST /v1/crunch when the bundle arrives as forty attachments and nobody is going to drag them across one at a time.
The scanned execution bundle is read by the local OCR engine, on your own CPU, and every line it produces is marked inferred rather than certain. Handwriting is not read: a manuscript signature or a margin note is reported as a page that needs a human, never guessed at.
A 200-page prospectus: rate tables by tenor and currency, a fee schedule, risk factors, and four pages of footnotes that every figure above depends on.
One document, and the page images alone outweigh everything else you were going to put in the request. Multiply by the shelf, then by every re-read of it.
Every cell keeps its row label and its column header. In a flat dump 3.75 arrives as a bare number and the model infers which tenor and which currency it belonged to — the one thing on the page nobody may infer.
Run the engine inside the perimeter, on your own servers. The base path is deterministic and makes no model call, so the prospectus never leaves the building in order to become Markdown, and the same bytes always produce the same output.
A cell merged across two columns is flattened into one. The conversion does not hide it: the response carries a warning naming the table, so you know which one to check by eye.
A 90-page clinical protocol: inclusion and exclusion criteria, a schedule-of-assessments grid, and a dosing table banded by weight.
Multiply it by every amendment and every sister protocol in the study folder, before the first question is asked.
A dose stays bound to its weight band and its unit. Flattened, 12.5 floats free of the band it belongs to — and a misattributed dose is not a formatting problem.
POST /v1/crunch from inside the pipeline. The base path is deterministic — same input, same Markdown, same structure map — which is what a validated system has to be able to say about a step.
Figures are not read. A structure diagram or a gel image comes back as a placeholder holding its position in the document, never as a description we generated for it.
A tender pack of about 300 pages: an ITT in PDF, the requirements matrix as XLSX, a question-and-answer addendum in DOCX, and two annexes nobody mentions until day nine.
That is the pack once. A bid team goes back into it a dozen times.
Requirement id, mandatory or desirable, and the response cell stay one row you can answer down. Flatten it and every M and D comes loose from the requirement it graded.
Drop one document here to see what comes back. Then run the engine over the whole folder: four formats, one command, one Markdown tree the entire bid team can search.
A 1998 photocopy of a statutory instrument goes through the local OCR engine, in seven languages, without leaving your network. What OCR cannot do is promise a clean read of a bad scan — so low-confidence lines are flagged per page and you get a list of pages to check, not a tidy document that is quietly wrong.
A 60-page component datasheet: parameter tables with min, typical and max columns, test conditions in footnotes, and dimension drawings at the back.
A part library holds hundreds of these, and every one of them gets revised.
The units row stays attached and a footnote marker stays in the cell it qualifies. Flattened, 2.7 3.3 3.6 is three numbers with no column and no test condition.
Run the engine across the library and rebuild it when a revision lands — the output is deterministic, so the diff is the revision. Point an MCP client at the result and an engineer can ask across the whole set instead of one datasheet at a time.
A dimension drawing is a figure placeholder. Its callouts live inside the image on a page that already has a text layer, so OCR is never invoked for them — the tolerances you can cite are the ones that were in a table.
Whatever the ticket has attached: a 40-page vendor PDF, an exported wiki page, a spreadsheet of test cases — arriving mid-conversation, in four formats, unannounced.
For one attachment, on one turn, inside an agent loop that had other things to spend a window on.
Headings come back as a structure map, so chunks can break where the document breaks instead of every thousand characters. A table survives inside the chunk that cites it.
The agent calls the crunch tool before it reads. The model sees Markdown; the raw file never enters the context window at all.
crunch.md does not chunk, embed or store anything. It returns Markdown and a structure map — the splitter, the index and the retrieval are still yours to write.
The six documents above are typical shapes, not files we converted, and nobody named here is a customer. The token figures are arithmetic on the same two per-page numbers the rest of this page uses: 2,134 tokens for a native document upload on Claude — 566 tokens of extracted text we measured, plus Anthropic’s documented 1,568-token page image — against 760 tokens of crunched Markdown. Change the page count and the arithmetic follows. Read the catches as the part we would rather you found here than after you uploaded something.