PDF to Markdown: What Actually Survives

PDF is a layout format — it describes where ink sits on a page, not what the text means structurally. That's fine for printing, but it's the wrong shape for anything that needs plain, structured text: pasting a report into an LLM prompt, dropping a spec into Notion or Confluence, or writing a GitHub README from an existing document. Markdown strips the layout and keeps the meaning — headings stay headings, lists stay lists — in a format any editor, wiki, or model can parse without fighting PDF's internal formatting. That's the actual use case behind most PDF-to-Markdown searches: not archiving, but reusing the content somewhere else.

Most PDFs don't carry real structural heading tags — visually, a heading is just text in a bigger font, with no metadata saying "this is H2." PixelTools' converter reconstructs headings from font size: it looks at the sizes used across the document, finds which ones sit meaningfully larger than the dominant body-text size, and buckets those into up to three heading tiers (H1, H2, H3). This is also why a numbered section like "2.1 Related Work" gets correctly recognized as a heading rather than misread as a numbered list item — font size wins over the numbering pattern, since a heading with a number prefix is still visually a heading first.

Be direct about this one going in: PDF tables don't come out as Markdown tables. The tool's own source comment explains the tradeoff: geometry-based table detection is "high-risk heuristic work that's hard to verify as correct rather than merely plausible-looking," so a table's text is left as ordinary paragraph text rather than reconstructed into a `|` grid that might be silently wrong. That's a real limitation, not a bug — a fabricated table that looks right but has cells shuffled is worse than no table at all. If your PDF is mostly tabular data, plan to rebuild that structure by hand after conversion.

Bulleted and numbered lists convert cleanly because they have an unambiguous signal: a literal marker character (•, ◦, ▪, -, *) or a numbering pattern ("1.", "2)") at the start of a line. The converter recognizes these and rewrites them as real Markdown list syntax (`- item`, `1. item`) instead of leaving the raw bullet character in the text. Separately, any Markdown special characters already present in the PDF's own text — asterisks, underscores, backticks, brackets, a stray leading `#` or `>` — get escaped, so body text that happens to contain them doesn't get misread as formatting once you paste the result somewhere else.

Academic PDFs and reports are full of repeating page furniture: a journal name in the header, a running title, page numbers like "Page 4 of 12." The converter strips both categories automatically. A line of text that repeats verbatim across three or more pages is treated as a running header/footer and removed. Separately, a bare number or "Page N of M" line that tracks the physical page index with a constant offset across three or more pages is detected and removed as a page number, even with no accompanying header text nearby. Both checks require three-plus pages deliberately, so a genuinely short one-page heading or a table's numeric value never gets mistaken for page furniture and dropped by accident.

Upload your PDF, optionally set a page range if you only need part of the document, and the conversion runs entirely in your browser via PDF.js — nothing is uploaded to a server, the same approach PixelTools uses for its other PDF tools. For best results, start with a text-based PDF rather than a scan; a scanned page has no embedded text layer for the converter to read, so you'd need OCR first. Once converted, copy the Markdown directly into an LLM prompt, a Notion page, or a README, and skim for any table sections — those are the one place you'll want to manually clean up the output.