PDF to MD

That is the case it was built for. Headings and lists survive, which is what a model needs to follow the structure of a document. Check any table before you rely on what a model says about it.

No. It reads the text layer already inside the PDF and applies layout rules. Nothing is sent to a model, so there are no tokens to pay for, no rate limit, and no queue between you and your file.

The header stripper is deliberately conservative. It removes a repeated line only when that line appears on most pages, sits in the top or bottom 15% of the page, and holds a stable vertical position across pages. A header that drifts fails the third test and is kept, because eating real content is a worse failure than leaving a header behind.

Only if it is a simple grid with at least three columns and at least three rows whose columns line up at consistent horizontal positions — the PDF format has no idea of a table, so this is inferred from where pdf.js says each fragment of text sits, not read from any table structure in the file. When that pattern holds, the rows come out as a real Markdown table with a header and a separator row. When it does not — a table with fewer columns, a merged cell, a cell that wraps onto a second line, or one row that does not line up — the detector deliberately backs off and prints the text as plain aligned lines rather than guessing at a structure it cannot confirm. Look at the output before you paste it somewhere that matters.

You get an empty file, and the tool says so rather than handing you a blank page silently. A scan is a photograph of a page: there is no text layer to extract, only pixels. Turning that into text needs OCR, which is a different job and is not what this does. If your PDF opens in a reader and you cannot select any text with the cursor, this tool has nothing to work with.

By font size relative to the rest of the document. It collects every distinct size, treats the most common one as body text, and ranks the larger sizes into heading levels above it. That works well on documents with consistent styling, which is most reports and papers. It misfires on decorative title pages, on documents that fake headings with bold body text rather than a larger size, and on slide decks where nearly every line is large.

The tool sorts text fragments by their vertical position on the page first, then horizontally. For single-column documents, this matches how you read. However, it reads across the entire page width rather than recognizing distinct columns, so text from the left and right sides of a multi-column layout often ends up interleaved line by line.

Each PDF can be up to 100 MB. There is no fixed page-count limit, but processing time and memory use depend on your device and the document. Large or image-heavy files can take longer even though the output contains only text.

Visible link text is extracted as plain text. Link destinations stored only in annotations are not extracted; a URL printed on the page may still appear as text. Images are not exported. Check links and tables before using the Markdown elsewhere.

Yes, for anything the PDF stores as real text, which includes accented Latin, Cyrillic, Greek and CJK. The part that degrades is heading detection, because it leans on font size and some typesetting traditions use weight or spacing instead. Right-to-left scripts extract correctly but the line order within a paragraph can come out reversed, depending on how the generating program wrote them.

For a text-heavy document, close. What usually needs a pass by hand is list nesting, since PDFs record indentation as horizontal position rather than as structure, and the occasional stray line break where the original wrapped mid-sentence. Everything else, including headings and paragraph boundaries, generally lands where you would put it yourself. Skim it once before committing rather than trusting it blindly.