Why I built pdf·markdown

You don't have to go all the way to a self-maintaining wiki for the point to land, though. Whatever your setup — a wiki, a RAG pipeline, or just dropping files into a chat — it all works better when the material is already clean Markdown.

Take Anthropic's write-up on how their teams use Claude Code — it's genuinely good, and it ships as a PDF. I dropped it into my setup, asked one question, and watched the model read the whole thing top to bottom just to find a single paragraph. A coding agent can't really search a PDF the way it searches plain text — grep, that instant "find this in the file" trick, comes up empty, because a PDF keeps its words locked in compressed, out-of-order binary. You'd have to unpack the whole file first. Same story with OpenAI's How OpenAI uses Codex, the AI Engineering ebook in my reading pile, half the papers worth reading in the field. All of it good; all of it stuck in a format my tools can't really read.

Leaving them as PDFs bugged me for two reasons. The first is plain cost. Every time I asked a question, the model had to re-parse the whole file from scratch — and on a 500-page PDF that's slow, and it quietly burns tokens on every single query. Converting it to Markdown once flips that around: a little work up front, and after that it's just readable. Cheap to search, cheap to ask about, for good.

The second reason matters more than it sounds. AI parsing isn't perfect — a formula drifts, a table collapses into a paragraph, a caption lands under the wrong figure. Pour that straight into your knowledge base and you've quietly stored noise; you might not notice until it hands you a wrong answer months later. So I'd rather convert it, actually look at the result, fix the handful of things that broke, and then save it. That one pass — me confirming it's right — is what turns a file into knowledge I trust. It isn't busywork; it's the most valuable step in the whole workflow. (It's also why the tool shows the original PDF and the Markdown side by side — so that check takes seconds, not an afternoon.)

And the Markdown doesn't replace the PDF — it sits in front of it. I keep both, linked together: the Markdown as the everyday, greppable layer my tools live in, and the original right behind it. Most questions never need more than the Markdown — but when a detail has to be exact, an agent can still open the PDF and read that one specific part. Nothing gets thrown away; the clean copy just makes the source easy to reach.

So I went looking for something that did this well. What I found was either ancient — tools that feel like relics from the last century — or just painful to use. You'd convert a file and get back a wall of text: no headings, no tables, never mind images or formulas. Proofreading that, let alone fixing it, was hopeless.

And one thing nagged at me the whole time. Some of what I work with is sensitive, and most of these tools want you to upload your file to their server before they'll touch it — I really didn't like the idea of my documents sitting on someone else's machine. So this one doesn't ask you to: the whole conversion runs locally, right in your browser. Your PDF is parsed by code on your own device — never uploaded, with no cloud API in the loop. There's nothing to trust me with, because I never receive your file.

So I built the thing I wanted.

And that's it — that's the tool. If it saves you one annoying round of copy-paste cleanup, it's earned its keep.

I'm still building it. If something breaks, a PDF comes out wrong, or you've just got an idea — I'd genuinely like to hear from you. Email me at hey@pdfmarkdown.app.