How to Convert PDF to Markdown
PDF and Markdown sit at opposite ends of the document spectrum. PDF fixes every glyph to a position on a page that will look identical everywhere; Markdown is plain text that describes structure and lets the reader decide the layout. Converting between them means rebuilding structure the PDF file itself never stored.
This guide walks through what that rebuild can and cannot recover, how to convert a PDF in this site's browser-based converter, what the LLM-optimized toggle changes, and the situations where a converter is simply the wrong tool for the job.
Why PDF and Markdown are opposites
A PDF is a print descendent: it records that a glyph sits at coordinate x, y, in a particular font at a particular size. Nothing in the file says "this is a heading" or "these three columns form a table." The structure you see on screen was reconstructed by the viewing application, and the file only stores the ink.
Markdown is the reverse. It stores almost nothing about appearance and everything about structure: a line starting with hashes is a heading, pipes delimit a table, indentation nests a list. The renderer decides fonts and spacing.
So a PDF-to-Markdown converter is really a structure detector. It reads positioned text, notices which lines were set larger and bolder, which gaps separate paragraphs, which rules align into a grid, and re-expresses those findings in Markdown syntax. The quality of a converter is the quality of that detection.
What a good conversion preserves
Reading order comes first. PDFs, especially two-column layouts, store text in an order that has nothing to do with how a human reads it. A converter must follow the visual flow: left column fully, then right column, headings in sequence, paragraphs in order. Get this wrong and the output is grammatically intact gibberish.
Heading levels come next. Body text, captions, and headings differ in font size and weight, and a converter maps those differences to #, ##, and ###. Perfect mapping is impossible on a document whose designer used a 13-point bold font for body text, but most real documents follow consistent conventions the detector can pick up.
Paragraph boundaries matter more than they seem. A PDF line break happens wherever the line happened to end on the page, not where the sentence ends. Rejoining those lines into single-line paragraphs is what separates Markdown you can edit from Markdown you have to repair line by line.
Converting a PDF in this tool
The converter runs entirely in your browser: the PDF parsing engine is WebAssembly compiled from Rust, and your file never leaves the device. Drop one or more .pdf files onto the page, and each one converts to Markdown in turn, with results shown in a preview panel alongside warnings for anything suspicious.
One warning worth knowing before you start: pages that contain no extractable text, typically scans or photographs of pages, produce nothing, and the tool tells you which page numbers are affected rather than silently handing you a half-empty document. That case has its own article, because the fix happens before conversion, not during it.
When conversion finishes, download the Markdown file directly, or convert several PDFs and grab them in one archive. Everything happens locally, so there is no file size limit beyond your device's memory and no queue to wait in.
The LLM-optimized toggle
By default, text output is wrapped so that lines stay within a readable width, the way pandoc and most text tools have behaved for decades. That wrapping is invisible in a rendered view but costs tokens and complicates diffing for machine consumers.
The LLM-optimized toggle disables the wrapping, so each paragraph is one long line. If you feed documents to ChatGPT, Claude, or a local model, single-line paragraphs tokenize slightly more efficiently, chunk cleanly on paragraph boundaries, and produce clean diffs when the source document changes.
The toggle also switches the PDF engine's extraction profile to its compact mode, which prefers tight, plain output over layout-faithful verbosity. Use it whenever the destination is a model; leave it off when the destination is a human editing the file in an editor that wraps lines for you anyway.
Tables: the hard part
Tables deserve their own article because they are genuinely the hardest object in the pipeline. The PDF format has no table concept; a table is just glyphs arranged in rows and columns, sometimes with drawn rules between them, sometimes with nothing but alignment.
This converter applies table structure recognition to those arrangements and emits GitHub-flavored pipe tables. Simple ruled tables, the kind with a line under the header and between rows, usually survive intact. Borderless tables, multi-level headers, and merged cells are where information gets lost or flattened, and the section on tables in the FAQ covers the details.
The practical advice is to expect correctness on clean tabular data and to verify anything numeric. A table that renders beautifully can still have shifted a single cell, and no visual inspection of the Markdown shows it. Compare a few cells against the original before trusting a converted table in production.
Beyond Markdown: HTML, RST and LaTeX
Markdown is the default destination, but the same pipeline can hand its output to a second stage running the pandoc engine, which is how the site produces reStructuredText and LaTeX from a PDF source. The PDF engine produces Markdown, and pandoc reads that Markdown and writes the requested format.
There is a reason the pipeline runs through Markdown instead of converting directly. Markdown is the most robust intermediate: pandoc's Markdown reader reconstructs an abstract document model from it, and the model drives every other writer. One extra hop, one well-tested path.
Use HTML output when you need to paste rendered content into a web page or email, RST for Sphinx documentation, LaTeX for papers. For most PDF sources, though, plain Markdown is the deliverable, and the other formats are conveniences rather than the point.
When conversion is the wrong move
Some PDFs are the wrong input entirely. Fillable forms carry their data in field structures, not in flowing text, so conversion yields the labels without the answers. Heavily designed documents, annual reports with charts as primary content, and anything where the visual arrangement carries meaning, like poetry with deliberate line breaks, will come out flattened.
Certificates, scanned IDs, and image-heavy slides are image documents wearing a PDF wrapper. No amount of conversion logic extracts text that is stored as pixels; that requires OCR, which is a preprocessing step this tool deliberately leaves to dedicated software.
For everything else, contracts, papers, reports, documentation, manual pages, conversion works and often works well. The fastest way to find out which side your document falls on is to convert it once and read the warnings: a clean run with no pages flagged is a strong signal the output is usable as-is.