Cutting Claude’s Token Bill by Converting PDFs to Markdown

Claude charges you twice for every PDF page, once for the text and once for the image. Converting to Markdown drops half the bill, as long as the document’s value is not in its figures.

A 50-page PDF can cost you 75,000 to 150,000 tokens before Claude has read a word of it. On a 200,000-token context window, that is most of your working space gone on one document. The reason is not the text, it is due to the way that Claude ingests a PDF.

Image generated with Midjourney

What a PDF actually costs

When you send a PDF to Claude through the API, two things happen. The system extracts the text, and it converts every page into an image. You pay for both. Anthropic’s own figures put the text alone at 1,500 to 3,000 tokens per page, depending on how dense the page is. The image cost sits on top of that, because each page is rendered and charged using the same calculation as any other image.

The dual cost is easy to miss, because it does not arrive as a separate line item. It is baked into the request whether or not the document has a single chart worth looking at. A plain-text technical manual pays the image tax in exactly the same way a figure-heavy datasheet does.

[embed]Embedded AI: Launch Updates and Early Access Sign up to receive launch updates for Embedded AI: Intelligence at the Edge, published by No Starch Press. You will be…embedded-ai.kit.com

The behaviour differs by entry point, and this is the API and Visual PDF path. A standard upload in the Claude app defaults to text extraction only unless you switch Visual PDFs on. So the saving below matters most when you are working through the API or building a pipeline, not when you drag a file into the chat window.

The fix is a format change

Markdown is plain text. Convert the PDF to Markdown before you send it and the image channel disappears completely. You are left paying for text and nothing else. You also tend to shed the layout debris that PDF text extraction includes: page headers, running footers, hyphenation artefacts, column breaks that land mid-sentence.

Microsoft’s MarkItDown does the conversion. There is an MCP server, markitdown-mcp, that provides access to the command, convert_to_markdown(uri), where the URI can point at a local file or a URL. Wire it into Claude Desktop or Claude Code and the model can pull a document in as Markdown without you converting anything by hand. For batch work, prepping a reading list or a corpus for retrieval, call the same library directly from Python and skip the MCP layer entirely.

Wiring MarkItDown into Claude

The easiest way to reach Microsoft’s MarkItDown library from Claude is the markitdown-mcp server. Install it with pip:

pip install markitdown-mcp

Then register it in Claude Desktop’s claude_desktop_config.json. The server uses STDIO by default, so the entry is short:

{
  "mcpServers": {
    "markitdown": {
      "command": "markitdown-mcp"
    }
  }
}

Where that config file lives depends on your platform:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json
• Linux: ~/.config/Claude/claude_desktop_config.json

If this is the first time you are changing the config, the file may not exist. If that is the case, open Claude Desktop, go to Settings, then Developer, then Edit Config (Figure 1).

Figure 1. Claude Desktop → Settings → Developer → Edit Config

That opens (and creates) claude_desktop_config.json in the right place, and you paste the JSON in.

{
  "coworkUserFilesPath": "/Users/dsuch/Documents/Claude",
  "mcpServers": {
    "markitdown": {
      "command": "markitdown-mcp"
    }
  },
  "preferences": {
    "coworkScheduledTasksEnabled": true,
    "ccdScheduledTasksEnabled": true,
    "sidebarMode": "chat",

    ...

}

After editing the file, quit Claude Desktop completely and reopen it. Closing the window is not enough, because the server only loads on a fresh start. Once it is running, point Claude at a file and it calls the conversion tool on its own:

The server exposes a single tool, convert_to_markdown(uri), which accepts http:, https:, file:, and data: URIs, so the same setup handles a local PDF and a remote URL without any change.

File meets Server, File loses Server

A local MCP server reads files the way any program on your machine does, by their path on disk. That sounds obvious until you remember what a Claude Desktop conversation actually contains. It is wired into two machines at once. One is your Mac, where a local STDIO server like markitdown-mcp runs. The other is a cloud sandbox, where Claude's code execution runs and where any file you drag into the chat is stored. The two do not share a filesystem, and most of the confusion around this tool comes from forgetting that.

We found this out by getting it wrong. After configuring markitdown-mcp on Desktop, we asked it to convert a PDF and got back "No such file or directory." The file plainly existed and the server was plainly running, so the error made no sense (Figure 2).

Figure 2. Trying to convert an uploaded PDF in Chat

The paths we were handing it looked like /home/claude and /mnt/user-data/uploads, which is where the cloud sandbox keeps things. Your Mac has no such directories. The local server was being asked to open files on a machine it was not running on, and it reported, correctly, that they were not there.

It is tempting to conclude that the server is sandboxed and cannot reach your disk. We believed that for a few minutes (Figure 3). It is wrong. The server reads your Mac fine; it just needs a path that exists on your Mac. Give it one and it works: point markitdown-mcp at file:///Users/dsuch/Downloads/report.pdf and it opens the file and returns the Markdown. The earlier paths failed because they pointed into the sandbox, not because the server was walled off from your disk.

Figure 3. MCP Tool Access Tests

So the rule is, address the file by where it lives on your disk, not by uploading it into the chat. An upload travels to the cloud sandbox, which your local server cannot see, and that is the one combination that fails. A path on your Mac is what the local server is built to consume. Spaces in the path have to be written as %20 in the URI, so Early Access Program.pdf becomes Early%20Access%20Program.pdf. The file scheme takes two slashes and the absolute path adds a third, which is why it reads file:///Users/... rather than file://Users/... (Figure 4).

Figure 4. The correct way to point the MCP command at a local file

The same logic carries to Claude Code and Cowork, which reference files by path as a standard practise.

Where this stops being a good idea

Stripping a PDF to Markdown throws away the visual channel. Charts, tables that exist as images, circuit diagrams, schematics, equations rendered as images: Claude can no longer see any of it. The image tokens you were so keen to avoid were paying for exactly that content.

So the rule is not “always convert.” For a datasheet where the answer you need lives in a timing diagram or a register table that ships as an image, the image tokens are the point. Convert that to Markdown and you get a cheaper request that can no longer answer your question.

The decision comes down to where the document’s value sits. Value in the prose: convert, and pocket the saving. Value in the figures: leave it as a PDF and pay for the pixels.

Measure before you commit

Before you wire this into a pipeline, run the token-counting API on a representative document both ways, as a PDF and as converted Markdown. The ratio you get back is the real number for your documents, not the rule of thumb above, and it will tell you quickly whether the conversion is worth the loss of the visual channel for the kind of material you actually process.

The interesting case is the 50 page report with three charts that matter. For this, convert the prose to Markdown and send only the pages that carry a figure as images. You pay the image tax on three pages instead of fifty.

My first book, Embedded AI, is published later this year by No Starch Press. It includes 25 hands-on hardware projects deploying machine learning on microcontrollers. Sign up for launch updates and bonus material! To support my writing here, please show your appreciation by following me, or subscribe to get an email whenever I publish a new article.

[embed]Embedded AI: Launch Updates and Early Access Sign up to receive launch updates for Embedded AI: Intelligence at the Edge, published by No Starch Press. You will be…embedded-ai.kit.com