PDF to Markdown vs HTML vs Plain Text

The first time I had to convert a stack of PDFs for a project, I picked plain text because it seemed simplest. Three days later I'd lost the heading structure, the tables were a mess, and I couldn't tell where one chapter ended. I redid the whole thing as Markdown and never looked back.

Here's how I think about the three formats now, and which one I'd pick for which job.

The short version

• Plain text: only when the destination strictly forbids formatting (some legacy systems, some grep pipelines).
• Markdown: my default for almost everything — notes, LLM input, drafts, version-controlled docs.
• HTML: when the document needs to render in a browser as the final form, especially with images, styling, or interactive elements.

For my own work — feeding API docs into Claude Code and processing research material for articles — Markdown wins almost every time.

What you keep and lose

A PDF carries text, structure (implicitly), tables, images, and styling. Each format keeps a different subset:

Plain text keeps text. That's it. Headings collapse into normal sentences, tables flatten to space-separated values, images vanish, links become bare URLs in parentheses or get lost. Reading order is preserved, which is the one thing it does have going for it.

Markdown keeps text, headings (via #), basic structure (paragraphs, lists, blockquotes), tables (via pipes), code blocks, links, and emphasis (bold/italic). It doesn't natively keep images as embedded data — they become links to image files. It doesn't keep page numbers, fonts, or absolute positioning, which is usually what you want.

HTML keeps essentially everything Markdown does, plus richer structure (custom classes, nested elements, embedded styling, embedded scripts, embedded images via base64). The downside is that HTML is verbose. A page of text becomes ten times its size in HTML if the converter is careless.

A quick example

Here's a small slice of an API doc, in each format.

Plain text loses the section, loses that "Authorization" was code, and loses the code block — you just get sentences run together with the example smushed into the prose.

Markdown gives you a heading, a paragraph, a fenced code block, and inline code. About six lines of source, all of it readable as text.

HTML gives you the same logical structure, but in tags: an h2, a p, a pre wrapping a code, with the same content nested inside.

If you paste any of the three into Claude and ask "what header should I send?", all three will probably get the right answer. But the Markdown and HTML versions reliably get a better-structured response back, because the model has the heading hierarchy as a map.

When I pick Markdown

• LLM input. Claude, GPT, Gemini all read Markdown structure as navigation. Headings give the model a map. I never feed plain text or PDF if I can help it.
• Notes and research. Obsidian, Logseq, and most note tools are Markdown-native. The format moves with my notes for years.
• Documentation. Most docs sites (Docusaurus, MkDocs, Astro) are built from Markdown. If my source is a PDF and the destination is a docs site, I convert to Markdown directly.
• Diff-friendly storage. Markdown lives well in Git. Changes are line-by-line, reviews are readable. PDFs and HTML diff badly.
• Plain reading. Markdown is readable as text even unrendered. HTML isn't.

When I'd pick HTML

• Final-form rendering. If the output needs to be a webpage, embedded styling matters. Markdown can render to HTML, but if the design is the point, going straight to HTML lets you control more.
• Email. Email clients render HTML, not Markdown.
• Documents with embedded media. A page where images and text need to flow together with custom positioning is more naturally HTML.
• Interactive content. If you need anything beyond static text, HTML is the format.

When I'd pick plain text

Honestly, almost never. The cases I've used it:

• Piping into Unix tools like grep or awk, where formatting just adds noise.
• Pasting into a system that strips formatting anyway, like an SMS or a legacy support ticket form.
• Quick eyeball checks where I just want the words and don't care about anything else.

For everything else, Markdown is a strict upgrade — it reads as plain text if you ignore the symbols, and it preserves structure if you don't.

What gets lost regardless

Some things don't survive any conversion from PDF. Page numbers and running headers (good — usually you don't want them). Fonts and exact spacing (good — these are presentation, not content). Footnote anchors (mixed — Markdown supports footnotes but most converters don't preserve the linking). Watermarks and annotations (depends on the tool).

I've stopped expecting perfect fidelity from any conversion. The goal is "a clean version of the content I can work with", not "a faithful reproduction of the original layout". If I need the layout, I keep the original PDF.

My actual workflow

For the two things I do most:

API docs into Claude Code. PDF → Markdown via PDF2MD → trim irrelevant chapters → paste. The Markdown is always the working format. I throw away the PDF after.

Research material into Obsidian. Mixed PDFs, web pages, and Word docs → Markdown (PDF2MD for PDFs, Pandoc for Word, browser save-as-markdown extension for pages) → drop into the article folder. Everything in one format means I can grep, link, and quote without context-switching.

If you're picking a format for a stack of PDFs and don't have a strong reason to do otherwise, Markdown is the right default.

Last updated: May 1, 2026