PDF to Markdown: What Survives Conversion (and What Breaks)

Short answer: headings, paragraph text, lists, and links usually survive a PDF-to-Markdown conversion. Tables, multi-column layouts, footnotes, and scanned (image-only) pages usually break — and no converter can recover what was never text. Your results depend almost entirely on how the PDF was made, not which tool you pick.

Why the source PDF decides everything

A PDF made from Word, Google Docs, or LaTeX carries an invisible text layer with font-size information. Converters use that layer to guess what is a heading and what is body text. A PDF made by scanning paper has no text layer at all — it is a photo of a page. Every "PDF to Markdown" tool that promises clean output from a scan is running OCR, which is a different (and much less reliable) process.

Quick test before you convert: open the PDF, try to select a sentence with your cursor. If you can select text, a text layer exists and conversion can work. If you cannot, the file is image-only and you need OCR first — or realistic expectations.

What typically survives

• Paragraph text — the core extraction almost every tool gets right.
• Simple bullet and numbered lists — when the original used real list formatting, not typed-out "1." characters.
• Headings — mapped from font size, so a 24pt bold line becomes an H1/H2. This is also where mistakes happen: a large pull-quote can be misread as a heading.
• Inline and external links — if the PDF has real link annotations.

What typically breaks

• Tables. The text layer is a stream of positioned characters; column boundaries are a guess. Simple 2–3 column tables survive. Financial statements and multi-level headers usually come out mangled.
• Two-column layouts (academic papers, newsletters). Text from both columns can interleave line by line unless the tool does layout analysis.
• Footnotes and endnotes — often dumped at the end or merged into body text.
• Math and code blocks. Equations become gibberish unless the tool has math-specific extraction; code loses indentation.
• Headers/footers and page numbers — repeated every page, they pollute the output unless the tool strips them.

Local vs. upload-based converters: the privacy difference

Most popular online converters upload your file to their servers. That is fine for a public menu PDF. For contracts, medical records, or internal documents, a browser-based converter that processes the file locally — the file never leaves your device — removes that exposure entirely. The trade-off: local browser extraction reads the text layer with JavaScript (no OCR), so it handles the "survives" list well and honestly refuses scanned pages instead of pretending.

A 3-step workflow that works

1. Check the text layer (select-text test above).
2. Convert with a tool that matches the file: browser-local for privacy-sensitive text-layer PDFs; an OCR pipeline only for scans.
3. Fix the three usual suspects in the Markdown output: misdetected headings (delete stray #), interleaved columns (manually re-order), and repeated headers/footers (search-and-delete). Ten seconds per page, usually less.

FAQ