Every PDF Converter Says It's 'For AI.' None of Them Count Your Tokens.

Search for a document converter and you will drown in the same three words: "for AI." PDF to Markdown, for AI. Word to Markdown, for AI. Convert your knowledge base, for AI. The phrase has become a reflex, printed on landing pages the way "artisanal" got printed on sandwich menus. It signals intent. It rarely describes a feature.

Here is the test that separates the label from the thing: after the tool hands you a Markdown file, does it tell you how many tokens that file is? Does it tell you whether that number fits inside the model you plan to use? Does it show you how the document would be split before you feed it to an embedding model? For nearly every converter on the market, the answer is no, no, and no. They produce a .md file and call the job done. But the .md file is the easy part. What happens after the file is where AI work actually lives, and that is precisely where these tools go silent.

The workflow they're pretending doesn't exist

Picture the thing you actually do. You have a 90-page vendor contract, or an annual report, or a research paper with dense appendices. You want to ask a model questions about it. So you find a converter, drop the PDF in, get a tidy Markdown file, copy the whole thing, and paste it into Claude or ChatGPT.

Then you hit a wall. The chat rejects it, or truncates it silently, or you get a length error that names a token count you have no way to verify. So you do the only thing the interface lets you do: you scroll to roughly the middle, select the top half, and delete it. Or you paste the second half in a follow-up message and hope the model stitches the halves together. You cut a 90-page document in half at a random page boundary — maybe mid-table, maybe mid-clause — because nothing in your workflow ever told you where the safe cut points were, or how big the document was to begin with.

That is the state of the art for most people. Not because they are careless, but because every tool in the chain treated "produce Markdown" as the finish line. The converter did its narrow job. The chat window assumed you would bring text that already fit. Nobody in the pipeline owned the question that actually mattered: will this fit, and if not, how should it be broken up?

"For AI" is a claim about the output, not the file format

Markdown is a reasonable format to hand a language model. It is compact, it preserves structure with cheap syntax, and headings survive as headings instead of dissolving into a wall of text. That part is real. But Markdown is not the reason a document works well with a model. It is table stakes. Converting a PDF to Markdown and stopping there is like a translator who hands you a perfectly grammatical sentence in a language you asked for, then walks away before telling you whether the person you're speaking to can hear you.

A model does not read files. It reads tokens, up to a hard limit called the context window, and it reads them with uneven attention — information buried in the middle of a long input is measurably harder for the model to recall than information near the start or end. So the questions that decide whether your AI task succeeds are all downstream of the file:

• How many tokens is this? Not pages, not words, not kilobytes — tokens, for the specific tokenizer your model uses.
• Does that number fit the model I chose? A document that sails into a 200K-context model will bounce off a smaller one.
• If it doesn't fit, where do I cut? And if I'm building retrieval, how do I split it so each piece stays coherent and carries enough context to be found later?

A tool that says "for AI" and cannot answer any of these is marketing a format, not solving a problem.

What actually closes the gap

The fix is not exotic. It is just work that converters have declined to do. Three things turn a Markdown file into something you can reason about before you paste it anywhere.

A live token count with a model selector. The moment the conversion finishes, you should see the token count — and it should change when you switch models, because tokenizers differ. MarkPrep uses gpt-tokenizer for exact counts on GPT-4o and the o-series, and shows clearly labelled approximate counts for Claude and Gemini, because those vendors don't publish a browser-runnable tokenizer and pretending otherwise would be dishonest. The point is that you see a real number attached to your real document, not a guess.

A context-window verdict. A raw token count is data; what you want is a decision. Pick your target model and the tool should tell you plainly: this fits, or this doesn't fit. That single verdict is the thing that would have saved you from the random mid-document cut. If a 90-page contract comes back as 140,000 tokens against a model that holds 128,000, you know before you paste that you have a problem to solve, and you can solve it deliberately instead of by deletion.

A visible chunk plan. When a document doesn't fit — or when you're feeding an embedding model with its own hard token ceiling — it has to be split. MarkPrep shows the split as a heading-aware chunk plan you can actually see and adjust. The default is 800 tokens per chunk with 100 tokens of overlap, adjustable anywhere from 100 to 2000, and it prefers to break at headings rather than mid-sentence. You are looking at the seams before you commit to them, not discovering them after your retrieval quality tanks.

Consider the same 90-page contract run through this workflow. Instead of a bare file and a shrug, you get: a count of, say, 140K tokens; a red "doesn't fit" against your 128K model; and a chunk plan that splits the document at its own section headings — "Indemnification," "Limitation of Liability," "Termination" — each chunk carrying its heading path so you know where it came from. Now the decision is yours to make with full information: switch to a larger-context model, or chunk it and retrieve the relevant sections. Either way, nobody cut a table in half.

The competitor comparison nobody wants you to run

Take a converter that markets itself explicitly "for AI" — markitdown.tech is a fair example; it wraps Microsoft's MarkItDown and produces clean Markdown from a range of formats. Now run the test from the top of this post against it. Where is the token count? Where is the context-window check? Where is the chunk preview? They ship the conversion. They do not ship the part that "for AI" implies. (They also process your files on a server, which is a separate conversation, and one worth having.)

This is not a knock on MarkItDown as a conversion engine. It is a knock on the category's habit of borrowing the credibility of AI without doing the specific, unglamorous work that AI pipelines require. Counting tokens is not hard. Checking a context window is arithmetic. Previewing chunks is a UI problem someone decided wasn't worth solving. The absence is a choice.

What "for AI" should have meant all along

MarkPrep's whole position fits in one sentence: everyone else stops at the file; we show you what your model will actually see. That means the token count is not an afterthought bolted on near the export button — it is the reason the tool exists. The conversion is the ticket in. The AI-Ready Pack — the live count, the model-aware verdict, the adjustable heading-aware chunks, and JSONL export with heading-path and page metadata for retrieval pipelines — is the product.

You can keep pasting whole documents and cutting them in half when they bounce. It works, in the sense that eventually you get an answer, from some fraction of the document, minus whatever fell off the edge. Or you can look at the number first.

Drop a document in and watch the token count appear — convert a file and see exactly where your model's limit lands. When you need to know before you paste, open the token counter and pick your model. The file was never the hard part. Knowing what your model will actually see is.