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
Most of a SharePoint estate has no native path into a model at all, and the part that does hits a hard page wall we have now hit from the outside. Where a comparison is possible it is a price, and that price 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.
| 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 | 358 pp | 755 pp | 359–755 pages |
| 200K | Haiku 4.5 | 80 pp | 211 pp | 81–211 pages |
crunch.md measured 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
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 once the context window is under 1M. That is documented — but it is also now measured: three of the 16 documents in our corpus were refused outright as native uploads on Claude Haiku 4.5, and all three counted without complaint as Markdown. This is not a saving. It is the difference between working and not working.
400 invalid_request_errormessages.0.content.0.pdf.source.base64.data: A maximum of 100 PDF pages may be provided.
crunch.md measured from the outside: three corpus documents of 194, 114 and 102 pages refused as native uploads on Claude Haiku 4.5, and all three counted without complaint as Markdown · read 2026-09-07
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.
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.
crunch.md all 16 documents, one row each, native and crunched totals · nothing averaged away, nothing left out — the worst document in the corpus is in this table · read 2026-09-07
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.md the same regulation, both language versions, same 88 pages, same counter · per-document rows in docs/measurements/native-token-cost.md · read 2026-09-07
crunch.md measured 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
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 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.
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
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.
crunch.md measured 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
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.
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
Anthropic published list prices, input tokens, standard (non-batch) rates · a snapshot, they move source ↗ · read 2026-09-07
crunch.md measured 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
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 $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.
HOW WE MEASURED
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 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,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. Read the catches as the part we would rather you found here than after you uploaded something.