Anything to Markdown. PDF, DOCX, PPTX, XLSX, PNG, JPG or a URL in — clean, structured, model-ready text out.
Drop it.
PDF · DOCX · PPTX · XLSX · XLS · HTML · CSV · MD · PNG · JPG · TIFF
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 engine on your own servers, in Python or a container. Nothing is uploaded: same bytes in, same Markdown out.
A crunch tool inside your agent loop. Point a client at mcp.crunch.md, or run the same four tools on stdio beside your files.
POST /v1/crunch. Markdown and a structure map back, synchronously. One key works here and on mcp.crunch.md — mint one
The demonstration. Drop one document, watch the engine work on it, and read the real measurements.
ANY MCP CLIENT — CLAUDE DESKTOP, CURSOR, A .mcp.json IN THE REPO
{
"mcpServers": {
"crunch": {
"type": "http",
"url": "https://mcp.crunch.md/mcp",
"headers": { "Authorization": "Bearer ck_live_..." }
}
}
}CLAUDE CODE
claude mcp add --transport http crunch https://mcp.crunch.md/mcp \
--header "Authorization: Bearer $CRUNCH_API_KEY"THE HTTP API, WITH THE SAME KEY
curl -X POST https://crunch.md/v1/crunch \
-H "Authorization: Bearer $CRUNCH_API_KEY" \
-F 'file=@report.pdf'mcp.crunch.md answers 401 to a request with no key — there is no anonymous path through it, and no unauthenticated endpoint of any kind on that host.
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.mdper 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
A twenty-year estate is PDFs, decks, workbooks and scans, and Markdown is the one shape all of them go into a model as. The whole document, too: the longest documents we measured are each a single request once crunched. Where a price comparison is possible it is a range rather than a number — 11.1% to 73.1% fewer input tokens a page, depending on what the document is. Five claims below, each with the figure it rests on, the spread behind that figure, and where both 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.
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.mdverified 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
| 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 |
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 · EVERY FORMAT, AND THE WHOLE DOCUMENT
Crunched, a 194-page protocol specification is 126,739 tokens of Markdown — one request, on the smallest model in the range. A native PDF upload is capped at 600 pages a request and 100 below a 1M window; Markdown is text, and text has no page limit — what fits is decided by the window, not by a page count, and the model reasons across all of it at once.
Anthropic's Files API takes no document block for DOCX, PPTX or XLSX — its own documentation says to convert them, so for most of a twenty-year SharePoint conversion is the route in. 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. §05 is what survives, item by item.
| Window | Models | Native | Crunched | Only works crunched |
|---|---|---|---|---|
| 1M | Fable 5.1, Opus 5, Sonnet 5 | 358 pp | 755 pp | 359–755 pages |
| 200K | Haiku 4.5 | 80 pp | 211 pp | 81–211 pages |
A long PDF can of course be cut up and sent in pieces, and the pieces are then reasoned over separately: ask which clauses reference one annex and you get two partial answers to reconcile by hand. The bill does not improve either — a page image is a flat 1,568 tokens whichever request it arrives in. What one context buys is one answer.
A request carries at most 32 MB, and a dense PDF can exhaust the context window before it ever reaches that. The Markdown of the same binder is a fraction of the bytes, so a binder that "should fit" does.
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.
AnthropicFiles API — no document block for DOCX, PPTX or XLSX; the documentation says to convert themsource ↗AnthropicPDF limits — 600 pages and 32 MB a request (100 pages below 1M); no premium on long contextsource ↗crunch.mdmeasured from the outside: the corpus’s three longest documents — 194, 114 and 102 pages — one request each as Markdown on Claude Haiku 4.5 · method and transcript in docs/claims-verified.md · read 2026-09-07
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.
53% fewer input tokens a page — 1,469 tokens a page that stop being billed. Page-weighted mean over 16 public documents; per document it runs 11.1% to 73.1%, and the table below says which is which.
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.
The same 16 documents, one row each, nothing averaged away and nothing left out — the worst document in the corpus is in this table. The median document reduces 55.4%; the floor is 11.1% and the ceiling is 73.1%. That spread is not noise. It is document type, and it is the part of this measurement you can actually apply to your own estate.
the notch in every bar is the published corpus mean, 53% — bars past it beat the headline, bars short of it do not
63.4% – 73.1% Prose under headings
Reports, memos, standards, briefs, specifications — pages someone wrote to be read. Little text under a full-page picture, so dropping the picture removes most of the bill.
44.6% – 59.6% Mixed pages
Statutes, statistical releases, charts and tables, research papers — and anything not in English, which tokenises worse on both sides of the comparison.
11.1% – 38.3% Dense grids and forms
Three-column instruction booklets, coordinate-positioned forms, equation-heavy papers. Reproducing a grid as Markdown costs close to what the page image saves. Better learned here than after converting an estate.
Dropping the picture is the whole mechanism, and the picture is a flat charge — it does not care what is printed on the page. 13 of the 16 documents save between 1,365 and 1,676 tokens a page, inside 15% of the 1,568-token page image, while their percentages run 38.3% to 73.1%. The percentage moves because the other half moves: a sparse memo has little text, so the constant is most of its bill; a dense booklet has a lot, so the same constant is a small share of it.
The 3 that save less — 368 to 1,141 tokens a page — are the densest layouts in the corpus: a two-column paper of mathematics, a three-column instruction booklet and a coordinate-positioned tax return. Rebuilding a grid as Markdown costs close to what dropping the picture saved.
So estimate your own estate in tokens, not in percent: 1,469 tokens a page stop being billed across this corpus, and 13 of the 16 sit within a fifth of that. What your percentage is depends only on how much text was sitting under the picture.
The GDPR is in the corpus twice — the English and the Hungarian text of one regulation, the same 88 pages. English reduces 59.3%. Hungarian reduces 46.2%. Same pages, so the same page image: 1,613 tokens against 1,610, measured.
What differs is the text, and it differs on both sides of the comparison. The same statute costs 1.69× as many tokens to extract in Hungarian (1,995 a page against 1,179) and 1.71× as many to write as Markdown. So the flat image charge is a smaller share of a Hungarian page's bill, and dropping it saves a smaller percentage.
The tokens hardly notice: 1,656 a page saved in English, 1,665 in Hungarian. If your estate is not in English, that is the number to plan with: the lower percentage is arithmetic, not a worse conversion.
crunch.mdall 16 documents, one row each, native and crunched totals · nothing averaged away, nothing left out — the worst document in the corpus is in this tablecrunch.mdthe same regulation, both language versions, same 88 pages, same counter · per-document rows in docs/measurements/native-token-cost.md · 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 5.1× 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.
Subtract a plain text dump from the native cost of the same document and what remains is the page image: a median of 1,569 tokens a page on Opus 5 and 1,568 on Haiku 4.5 — the same number on both sides of a supposed visual-tier boundary. So the high-resolution 4,784 figure does not describe a rendered PDF page. The cheapest check needs no arithmetic at all: a one-page PDF in the corpus costs 3,007 tokens in total on Opus 5, and a page cannot cost less than its own image. Anthropic's worked example implies about 2,333 tokens a page — the same order as the 2,792 we counted.
Pipes, hashes and dashes cost 1.07× a bare text dump — 1,323 tokens against 1,239. There is no saving against plain text and we do not claim one: what the extra buys is the grid, the heading tree and the numbering, and that is what turns an extraction into something a model can navigate.
crunch.mdmeasured over 16 PUBLIC PDFs, 861 pages, counted with Anthropic messages.count_tokens · corpus manifest and fetch script in the repo, so anyone can re-run itAnthropicPDF support — the system converts each page into an image, and extracts the text alongside itsource ↗Anthropicvision — a page image is billed in 28×28 pixel patches, capped at 1,568 visual tokens on the standard tiersource ↗Googledocument processing — each PDF page counts as a flat 258 tokens, and Gemini 3 does not separately charge for the text it extractssource ↗crunch.mdmeasured page-image cost: native document cost minus a plain text dump of the same pages, same model · median 1,569 on Opus 5 and 1,568 on Haiku 4.5 · docs/measurements/native-token-cost.md · read 2026-09-07
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. It applies the corpus mean to your page count; if your estate is mostly reports or mostly forms, §03 says how far either way that moves.
List price for input tokens, standard rates. Output is the same either way, so it is not counted here.
YOU KEEP $7,345 on every pass
Anthropicpublished list prices, input tokens, standard (non-batch) rates · a snapshot, they movesource ↗crunch.mdmeasured over 16 PUBLIC PDFs, 861 pages, counted with Anthropic messages.count_tokens · corpus manifest and fetch script in the repo, so anyone can re-run it · read 2026-09-07
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 $2,130 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.
16 public multi-page PDFs — arXiv papers, NIST standards, an RFC, the GDPR in
two languages, IRS forms, a Federal Reserve statistical release, scanned court and statute
pages — 861 pages in total. Not our own documents: public ones, listed by URL and
sha256 in the repo, so the corpus is something you fetch rather than something you take our
word for. Token counts come from Anthropic messages.count_tokens, Claude's own counter for the model
being quoted, not a third-party tokenizer or a heuristic. Mean 1,224 tokens of extracted text a page in, 1,323 tokens of Markdown
out. Every one of those 16 documents is printed on this page with its own
result, in §03, rather than summarised into a single percentage: a mean over an arbitrary
corpus is not a benchmark result, and the worst document in the corpus is in the table with the
best. 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 from that corpus, 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 where it hands the page back to you.
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 labelled inferred rather than certain. It declines to guess at handwriting: a manuscript signature or a margin note comes back named as a page for a partner to check, so nothing invented ever reaches the model.
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.
Every merged cell is reported. One spanning two columns is flattened into one, and the response names the table it happened in — so the desk gets a short list to check by eye rather than a number that quietly moved.
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.
Nothing on the page is described by a model that did not read it. A structure diagram or a gel image comes back as a placeholder holding its position in the document, never as a caption we generated for it — so what reaches the submission came off the page.
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 — and every low-confidence line is flagged on the page it came from. A bad scan comes back as an exact list of pages to check, which is what a bid team can act on, rather than 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.
Every tolerance that was in a table comes through as a table cell you can cite. A dimension drawing comes back as a figure placeholder holding its position: its callouts live inside the image on a page that already has a text layer, so nothing there is guessed at on an engineer’s behalf.
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.
It returns Markdown and a structure map, and stores nothing. The splitter, the index and the retrieval stay exactly as you built them — adopting this is one call in front of the pipeline you already have, not a pipeline to replace.
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,792 tokens for a native document upload on Claude — 1,224 tokens of text the model extracts, plus a 1,568-token page image, both measured — against 1,323 tokens of crunched Markdown. Change the page count and the arithmetic follows. Each panel also names the work that stays yours on that desk, because a limit you find here is worth more than one you find after converting an estate.