Markdown is the best format to feed an AI: it is the leanest in tokens, and its structure survives the trip into the model untouched. DOCX comes second, and only when you upload it directly so the tool can walk the document model. PDF is the format most likely to garble tables, headings, and reading order.
You paste a 30-page DOCX into ChatGPT and ask it to summarize section three. The answer rambles about the cover page and ignores the table of contents. You try a PDF instead. This time the model invents a quote that does not appear in the document. You give up, copy the text manually into the chat window, and suddenly the model answers everything correctly.
The frustration is real. The lesson is simpler. The format you feed an LLM determines what it actually sees, and most formats hide more than they show.
This post compares the three formats most people send to LLMs in 2026: markdown, DOCX, and PDF. We look at what each one is under the hood, what it costs in tokens, what structure survives the trip into the model, and which format is the right choice for which job.
Three Formats Built for Three Different Jobs
Markdown, DOCX, and PDF were each built with a specific reader in mind. None of those readers were language models.
Markdown was designed by John Gruber in 2004 for human writers who wanted a way to draft for the web without dealing with HTML. It is plain text with light syntax. A pound sign is a heading. An asterisk is emphasis. A hyphen at the start of a line is a list item. The whole format fits on a page of documentation, and the file you write is the file the parser reads.
DOCX is Microsoft’s Word format, a zipped bundle of XML files that describes paragraphs, runs, styles, comments, revisions, embedded objects, and the relationships between them. It was built for word processors and the people who use them. The output is a document that prints predictably and can be edited collaboratively with track changes and comments preserved across versions.
PDF is Adobe’s portable document format, designed in 1993 to make a document look identical on every screen and every printer. Under the hood, a PDF is a stream of drawing instructions. Place this glyph at these coordinates. Stroke this line at this thickness. The format does not know what a paragraph is. It knows where ink goes.
Three formats, three jobs. Markdown serves the writer. DOCX serves the editor. PDF serves the reader and the printer. None of them were built for a model trying to understand what a document means.
What Each Format Looks Like Inside an LLM
The difference between formats is invisible until you look at what actually arrives in the model’s prompt.
Take a single sentence: “Revenue grew 34% year-over-year, driven by expansion into European markets.”
As markdown:
Revenue grew 34% year-over-year, driven by expansion into European markets.That is what the model sees. The text is the text. No styling, no metadata, no structural baggage.
As raw DOCX XML, which is what you find if you unzip the .docx file and open the document.xml inside:
<w:p>
<w:pPr><w:pStyle w:val="Normal"/></w:pPr>
<w:r>
<w:rPr><w:rFonts w:ascii="Calibri" w:hAnsi="Calibri"/><w:sz w:val="22"/></w:rPr>
<w:t>Revenue grew 34% year-over-year, driven by expansion into European markets.</w:t>
</w:r>
</w:p>The same sentence, wrapped in style attributes the model has to parse before it can find the actual content. Modern chat tools do not show you this XML when you upload a DOCX, but if your tool extracts text without going through the document model, you can end up with bracketed style fragments mixed into the prose.
As PDF text extraction, which is what a basic copy-paste from a PDF reader produces:
Q3 2025 Financial Summary | Page 3
Revenue grew 34% year-over-year, driven by
expansion into European markets.
Q3 2025 Financial Summary | Page 4The sentence breaks across a page boundary. The header repeats. There are no paragraph markers, no structural cues the model can use to separate running text from page furniture.
Same sentence, three formats, three very different inputs. The model only ever sees what arrives in the prompt. Format determines what arrives.
Token Economics Across the Three Formats
Tokens are what LLMs charge for, attend to, and run out of. The format you send shapes the token bill in ways that are easy to miss.
Take a typical 1,000-word source document, like a product specification or an internal memo. The same content, in three formats, lands roughly like this:
| Format | Approximate tokens | What’s in there |
|---|---|---|
| Clean markdown | 1,300 to 1,500 | Just the text and structural syntax |
| DOCX (uploaded to a chat tool) | 1,300 to 1,800 | Tool extracts cleanly before tokenizing |
| DOCX (raw text copy-paste) | 1,500 to 2,500 | Text plus residual style metadata and inconsistent spacing |
| PDF (text extraction, simple layout) | 1,800 to 2,500 | Text plus page headers, footers, and forced page breaks |
| PDF (multi-column or scanned) | 3,000 to 6,000+ | Plus interleaved columns and OCR noise |
The numbers are approximate, but the pattern is consistent. Markdown is the lean baseline. DOCX adds modest overhead when handled by a smart tool, and a lot more when you copy-paste raw text out. PDF is the wildcard. A clean single-column report behaves close to markdown. A scanned magazine or a financial PDF with layered tables can balloon to four times the tokens with worse output to show for it.
Every extra token does three things, all of them bad. It costs money on the API. It eats your context window. It dilutes the model’s attention away from the parts that matter. The guide to reducing LLM token usage covers this dynamic in detail.
Structural Fidelity: What Actually Survives Conversion
Tokens are only half the story. The other half is whether the structure of the document survives the journey from file to prompt.
Headings tell the model where one topic ends and the next begins. Lists communicate enumeration. Tables carry rows and columns. Code blocks signal “do not interpret this as prose.” When structure is lost, the model has to guess, and it usually guesses badly.
Markdown preserves structure by design. The syntax is the structure. An H2 in the source is an H2 in the prompt. A bullet list stays a bullet list. There is no “conversion step” because there is nothing to convert.
DOCX preserves structure when handled by a tool that understands the document model. Modern chat interfaces do this well. When you upload a .docx to ChatGPT, Claude, or Gemini, the tool walks the XML, pulls out paragraphs and headings in order, and feeds the model a structured representation. Comments, track changes, and embedded objects are usually dropped, which is fine for most AI tasks. Where it falls apart is when the document was authored in a chaotic way, with manual line breaks instead of paragraph breaks, or with headings styled by hand-set font sizes instead of heading styles. The tool has nothing to walk, and the structure leaks through to the prompt as flat prose.
PDF rarely preserves structure cleanly. Headings might be larger text on the page but carry no semantic tag. Tables look like tables on screen but extract as flat character streams. Multi-column layouts produce interleaved output where left-column text bleeds into right-column text. Scanned PDFs are not text at all until OCR runs over them, and OCR adds its own errors. The PDF to markdown guide covers why PDFs are uniquely difficult and what you can do about it.
Round-tripping makes the difference visible. If you take a markdown file, convert it to DOCX, then back to markdown, you get something close to the original. If you convert markdown to PDF and try to extract the text again, you usually do not. The format that carries the least style baggage survives the trip best.
When DOCX or PDF Is the Right Input (Yes, Really)
The honest answer to “which format should I use for AI workflows” is not always markdown. There are jobs where DOCX or PDF is genuinely the better choice, and pretending otherwise produces brittle workflows that break in real conditions.
DOCX is the right input when:
- The source is a Word document and the comments, track changes, or revision history matter to your prompt. You are asking the model to summarize editor feedback or reconcile competing edits.
- Your team authors and reviews in Word. Forcing a markdown layer between the author and the model adds friction that nobody asked for.
- The document has rich structured content (footnotes, cross-references, captions) that DOCX represents natively and markdown approximates poorly.
PDF is the right input when:
- The document only exists as a PDF. Legal filings, scanned contracts, archived reports, government datasets. The PDF is the source of truth and rejecting it is not an option.
- The document was designed for the page (financial statements, regulatory submissions, formal proposals) and reformatting strips signal that a human reader would catch.
- You need to preserve page references for citation. “Page 14, paragraph 3” is meaningful in a PDF and meaningless in markdown.
In both cases, the format choice is about the workflow, not about what the LLM prefers. Convert when you can. Send the original when you must.
Why Markdown Wins for Most AI Workflows
For everything else, which is to say the long tail of web research, knowledge bases, prompt engineering, RAG pipelines, repository analysis, and content drafting, markdown is the right default.
Headings become chunk boundaries. RAG pipelines split documents along H1 and H2 lines. Markdown gives the splitter unambiguous breakpoints. DOCX styles work too, but only after a parser walks the XML. PDF gives no help at all.
Lists, tables, and code blocks survive. A bulleted list in markdown reads as a bulleted list to the model. A fenced code block tells the model “this is code, not prose.” That guidance changes how the model attends to the content.
Token efficiency compounds. Across a 10,000-document pipeline, the difference between 1,400 and 2,400 tokens per document is millions of tokens per day. At scale, format choice is a line item on the bill.
The format is diffable and version-controllable. You can put a markdown document in git, see what changed between versions, and feed the diff to a model. DOCX diffs are nearly unreadable. PDF diffs are useless.
Every modern LLM eats markdown natively. No tool layer is required. No pre-processing. Just paste it in or send it through the API.
This is why markdown has quietly become the lingua franca of AI input. Not because it is fashionable, but because every other format gives the model less to work with. The broader case for markdown as LLM input walks through the specifics if you want the longer argument.
A Practical Decision Framework
Here is the rule of thumb for choosing a format and getting from your source to clean LLM input.
| Your source is | Do this |
|---|---|
| A web page or article | Convert to markdown with CopyMarkdown’s web converter. One click, no nav bars or cookie banners. |
| A PDF | Convert with CopyMarkdown’s PDF converter. Watch tables and multi-column layouts in the output. |
| A GitHub repository | Flatten the codebase into a single markdown file with CopyMarkdown’s repo converter. |
| A DOCX | Upload it directly to ChatGPT, Claude, or Gemini. They handle .docx natively and extract structure cleanly. If the output looks rough, save the DOCX as PDF first and run it through the PDF converter. |
| Already markdown | Use it as is. You are done. |
| A scanned image or scanned PDF | Run OCR first, then convert. The quality ceiling is set by the OCR step. |
The pattern is consistent. Get to clean markdown when you can. When the source is DOCX, lean on the model’s own file upload. When it has to be PDF, accept that conversion is lossy and verify the output before trusting it downstream. When you are dealing with web content at any scale, the RAG content prep guide covers the steps after format conversion.
The best format for AI workflows is not always markdown. It is the format that preserves the information your prompt depends on with the least token overhead. For most people, most of the time, that is markdown. For the cases where it is not, this framework points to the next best path.
Markdown vs DOCX vs PDF: FAQ
Can AI read DOCX better than PDF?
Generally yes. A DOCX is a structured document model that chat tools can walk cleanly: paragraphs, headings, and lists come out in order. A PDF is a stream of drawing instructions that has to be reverse-engineered back into text. When you have both versions of a document, upload the DOCX. When you can get clean Markdown, use that instead.
What is the best file format to upload to ChatGPT?
For file uploads, DOCX extracts more reliably than PDF. For maximum control, paste Markdown directly into the prompt: you decide exactly what the model sees, and it costs fewer tokens.
Should I convert a PDF to Markdown before uploading it?
If the PDF is scanned, table-heavy, or long, yes. The PDF to Markdown for ChatGPT guide walks through the decision case by case.
Does this apply to Claude and Gemini too?
Yes. The differences described here come from the formats themselves, not from any one model. Claude, ChatGPT, and Gemini all read Markdown natively and all inherit the same extraction problems with PDF.
What to Read Next
This post compared formats at the input layer. Once your input is clean, the next questions are about token use and structure inside the prompt.
For why every token matters and how to cut bloat without losing meaning, see How to Use Fewer Tokens and Get Better LLM Results.
For the broader argument for markdown as the universal LLM input format, see Markdown for LLMs: Prepare Web Articles for AI.
For preparing markdown content for retrieval pipelines (chunking, embedding, validation), see the guide to preparing web content for RAG.
For making your own site machine-readable to AI agents at the structure level, llm.txt is the emerging standard.