Why a PDF is hard for an AI to read
A PDF was built to look the same on every screen and printer, not to be read by a machine. Inside the file, your text is not stored as flowing sentences. It is stored as thousands of small instructions that place each character at an exact point on the page, next to font tables, embedded metadata and layout data. A person sees a clean page. A language model sees that raw stream, and it has to spend tokens working through all of it before it reaches your actual words.
Markdown is the opposite. It keeps the parts that carry meaning, the headings, paragraphs, lists and tables, and writes them as plain text with a few light symbols. A model reads that the way it reads most of its training data, so it spends its attention on your content rather than the packaging around it.
What the converter actually does
When you drop a PDF here, the tool reads the file’s text layer, meaning the real, selectable characters stored inside it, and works out the reading order, the headings and any tables it can find. It then writes that out as Markdown, so a top-level title becomes a heading, a bulleted list stays a list, and a simple table becomes a Markdown table with a header row. The open-source MarkItDown engine runs inside your browser through WebAssembly, so the file never leaves your device and nothing is uploaded to a server.
The result is plain text you can paste straight into ChatGPT, Claude, Gemini or Copilot, or load into a RAG pipeline or a vector database. There is no account, no install and no Python to set up, even though MarkItDown is normally a Python library.
The token and cost angle
The clearest reason to convert first is cost. Most paid AI tools bill by the token, and a PDF carries a lot of tokens that say nothing about the content. Reducing it to Markdown commonly cuts the token count of a document by 30 to 60 percent, depending on how much layout and formatting the original carried. Fewer tokens means a smaller bill on every request and more room left in the context window for the model to reason over what you sent.
For retrieval the win is about accuracy more than price. A RAG system splits a document into chunks before it searches them. Raw PDF text has no clean structure, so a naive splitter cuts a chunk in the middle of a sentence or a table, and the resulting embeddings represent position on the page instead of meaning. Markdown gives the splitter real boundaries to work with. You can chunk on headings and sections, each chunk stays about one thing, and retrieval gets noticeably more accurate as a result.
Which PDFs convert best
The sweet spot is any text-first document: reports, research papers, contracts, manuals, whitepapers, meeting notes and books exported to PDF. These are mostly prose and simple tables, which is exactly what Markdown handles well, and they tend to be the documents people most want to feed to an AI in the first place.
Forms, invoices and financial statements sit in the middle. The text converts, but the layout that made them readable on paper does not always survive, so it is worth checking any figure that matters. Image-only material, such as a scanned receipt, a printed contract that was scanned back in, or a photo of a page, sits outside what this tool can do, because there is no text in it to read.
Where PDF conversion gets messy
It is worth being honest about the limits. PDFs do not really store the structure you see on screen, so the converter has to infer it, and some layouts make that hard. Pages laid out in two or more columns can come out with the text interleaved when the reading order saved in the file is unusual. Tables with merged cells, stacked headers or cells that wrap onto several lines are the most common thing to come out rough, because a PDF stores a table as lines and positioned text, not as real rows and columns.
Heavily designed pages, like magazine spreads or marketing one-pagers, convert less cleanly than a plain report or a contract. If a converted table looks scrambled, that usually means the original was complex, not that something went wrong. The quick fix is to copy just that section on its own, or to keep the source file handy for anything where the exact numbers count.
Scanned PDFs and why there is no OCR
Two PDFs can look identical on screen and behave completely differently here. A born-digital PDF, exported from Word, a browser or a design tool, has a real text layer underneath. A scanned PDF is a photograph of a page wrapped in a PDF, with no text under it, only an image. This tool reads text, so a scan comes back empty. It does not run OCR, the separate process that recognises letters inside an image.
There is a one-second test before you convert. Open the PDF in any viewer and try to select a sentence with your cursor. If the text highlights, the file has a text layer and it will convert here. If your cursor only draws a box over a picture and nothing highlights, the file is a scan, and you would need an OCR step first to pull the words out.
Getting the cleanest result
A few habits make a real difference. Start from the original export rather than a printed and rescanned copy whenever you can, since a born-digital file always converts better. Keep files under the 15 MB limit, and split a very long PDF into parts if your browser runs low on memory on a big one. After converting, skim the Markdown for any table that looks off and tidy those by hand, since tables are the part a model is most likely to misread. For everything else, the output is ready to paste into your AI tool exactly as it comes out.