PDF → Markdown

If you have ever run pandoc input.pdf -o output.md and gotten an error instead of Markdown, you did not misconfigure anything. Pandoc has no PDF reader. That is a design decision rather than a missing feature, and understanding it tells you which workaround is actually worth your time — and when converting a PDF to Markdown with an online tool is simply the faster path.

Why Pandoc Cannot Read PDF Input

Pandoc works in three stages: a reader parses a source file into an abstract syntax tree (AST), filters can transform that AST, and a writer serializes it into a target format. Readers exist for formats that carry explicit structure — Markdown, HTML, LaTeX, DOCX, ODT, EPUB, reStructuredText, Org, and others. PDF is not among them, and it is unlikely to be added. For Pandoc, PDF is an output format, produced through a LaTeX, ConTeXt, or HTML/CSS engine.

Pandoc needs structure; PDF stores coordinates

A Pandoc reader must know where a heading begins and ends, what belongs to a list, and which cells form a table. A PDF contains almost none of that. Inside a typical PDF you find glyphs placed at x/y positions, drawing operators that paint rectangles and rules onto a page, and font resources. Paragraphs, columns, and headings are visual conventions that humans recognize and software has to guess.

The specific reasons PDF parsing is hard

• No reading order. The order in which text is drawn is not necessarily the order a human reads it, especially with two-column layouts, sidebars, and floating figures.
• Encoding gaps. Many fonts lack a ToUnicode map, so extraction yields ligature artifacts such as fi rendered from a single glyph, or (cid:42) placeholders.
• No semantic tags. Tagged PDFs exist, but most documents produced by word processors, LaTeX, and print pipelines are untagged.
• Tables are geometry. A table is a set of ruling lines with positioned text, not rows and columns — which is why converting PDF tables to Markdown is its own problem.
• Scanned pages contain no text at all. OCR is a separate pipeline that Pandoc plays no part in.

Shipping a PDF reader would mean embedding layout analysis, font heuristics, and OCR inside Pandoc. That is a different category of software, and the project deliberately leaves it to other tools.

Workaround 1: pdftotext, Then Pandoc

The most common route pairs Poppler's pdftotext with Pandoc for the final serialization step.

1. Extract text: pdftotext -layout input.pdf output.txt. The -layout flag preserves visual arrangement, which helps tables and hurts flowing prose; -raw keeps content-stream order instead.
2. Convert to Markdown: pandoc output.txt -o output.md.
3. Clean up by hand or by script.

Step 3 is where the time goes. Pandoc's plain-text reader treats blank-line-separated blocks as paragraphs, so you get reasonably clean prose but zero structure — no headings, no lists, no tables. Typical cleanup means rejoining hard-wrapped lines, fixing words split across line breaks, deleting running headers and page numbers, and re-adding # markers where headings used to be.

Workaround 2: a Python pipeline

When manual cleanup stops being practical, Python libraries expose what pdftotext discards. PyMuPDF (imported as fitz) returns each text span with its font name and size, which is enough to infer heading levels. pdfplumber is stronger on ruled and borderless tables. Higher-level wrappers such as pymupdf4llm and marker combine layout detection with optional OCR and emit Markdown directly. The trade-offs are real: dependency installs, model downloads, slower runs on large batches, and tuning when your documents do not match the defaults.

In practice this becomes a pipeline: extract, detect headings from font metadata, convert tables separately, then pass the assembled Markdown through Pandoc when you need a different output format. A concrete version of that flow is described in this PDF to Markdown workflow.

Workaround 3: get to DOCX first

Pandoc's DOCX reader is one of its best. Headings, lists, tables, footnotes, and emphasis all survive. So if a tool can give you a structured DOCX from the PDF, pandoc document.docx -o document.md produces far better Markdown than any text-based route. The catch is that quality now depends entirely on the PDF-to-DOCX step, which faces the same layout problems — you have moved the hard part, not removed it.

Limitations That Follow You Into Every Text-Based Workflow

What the PDF holds	What plain extraction gives you
Heading in a large bold font	An ordinary line of body text
Table with ruling lines	Columns of words in jumbled order
Two-column body text	Lines interleaved from both columns
Footnote markers	Numbers with no links to the notes
Inline equations	Garbled glyph runs, or nothing
Scanned page image	Empty output; OCR required

None of these are Pandoc bugs. Pandoc receives whatever the extractor hands it, and by that point the structural information is already gone.

When a Dedicated Online Converter Is the Faster Path

A browser-based converter earns its place when the document is a means to an end rather than a project:

• One-off papers, standards, reports, or vendor PDFs you need in Markdown once.
• Scanned documents, where OCR has to be part of the conversion anyway.
• Headings and tables that need to come out as real Markdown on the first pass.
• No local toolchain — a browser-only machine, a locked-down work laptop, or a teammate who will not install Poppler.
• Pasting into Obsidian, Notion, or an LLM context window, where you want clean Markdown now and do not need a reproducible script.

The free converter at pdf.my99ai.com handles the common cases: upload the PDF, get Markdown with # headings, lists, and pipe tables, with the install and tuning steps removed. Local pipelines still win for large batches, strict privacy requirements, and reproducible builds where every step is scripted and version-pinned. The rule of thumb is simple: if you will run the conversion more than a few dozen times, automate it; if you need the Markdown today, convert it.

FAQ

Can Pandoc convert PDF to Markdown with a filter or plugin?

No. Filters and custom writers operate on Pandoc's AST, and building that AST requires a reader. Since no PDF reader exists, there is nothing for a filter to run on. Every "Pandoc PDF" solution you find online is really a separate extractor plus Pandoc.

Is pdftotext plus Pandoc good enough for academic papers?

For simple single-column papers with little math, it yields readable prose that needs manual heading and list cleanup. For two-column layouts, equations, and footnote-heavy text, expect substantial rework, or use a layout-aware extractor first and keep Pandoc for the final format conversion.

Does converting the PDF to DOCX first really help?

Yes, when the DOCX conversion is good. Pandoc's DOCX reader preserves structure, so the Markdown it writes keeps headings, tables, and footnotes. The limitation is inherited: a DOCX built from a messy PDF carries the same jumbled reading order and broken tables, just in a different container.