PDF to Markdown Converter_
A PDF is drawing instructions, not a document. It records glyphs at coordinates and sizes; it does not record that something is a heading, a paragraph, a list or even which order to read the columns in. Everything structural below is inferred, and the panel above says how confident that inference is.
The case worth knowing before you start: if the PDF was scanned or photographed, it contains no text at all — only a picture of text — and every converter on earth returns nothing. That is not a failure, and the page says so plainly rather than handing back a blank box.
- Input
- A PDF up to 25 MB, opened inside this page. Nothing is uploaded, which is the whole reason to do this in a browser: PDFs are contracts, statements, medical letters and unreleased reports.
- Output
- Markdown with headings inferred from type size, lists recognised from their bullets, and paragraphs inferred from vertical gaps. Plus a report saying how much of that was guesswork.
- Processing
- Text extraction by PDF.js, Mozilla's renderer — the same engine Firefox uses to display PDFs. Layout inference is done here on the positions it reports.
- Limits
- No optical character recognition. A scanned page contains an image, not characters, and this reads characters. Tables, multi-column layouts and footnotes have no reliable representation and come out as ordinary lines.
- Why headings are a guess
- HTML says "this is an h2". A PDF says "draw these glyphs at 18 points". So heading detection means measuring the most common type size in the document, calling that the body, and promoting anything noticeably larger. It works well on reports and articles and badly on documents typeset without size hierarchy — and when there is no variation to read, the page tells you no headings were found rather than inventing some.
A PDF does not know what a heading is
What the format actually stores
PDF is a page-description language descended from PostScript. Its content streams say "set this font at this size, move to these coordinates, show these glyphs" — and that is genuinely all. There is no element tree, no semantic markup, and no reading order beyond the sequence the generator happened to emit. Two visually identical pages can have completely different internal structure depending on which program produced them, which is why converting the same-looking document from Word and from LaTeX gives noticeably different results.
Scanned pages contain no text whatsoever
A page produced by a scanner or a phone camera is a single image wrapped in PDF packaging. There are no characters to extract, so extraction returns an empty string — correctly. The test is quick: try selecting text in a PDF viewer, and if nothing highlights, there is nothing there. Turning that back into text requires optical character recognition, which is a different technology with different failure modes, and this page does not attempt it. Some scans are run through OCR at creation and do carry a hidden text layer; those extract normally, and the confidence figure will tell you which kind you have.
Tables and columns are where inference gives up
A table in a PDF is text positioned in a grid, sometimes with lines drawn near it. Nothing marks a cell boundary, so recovering the table means guessing which items belong to which column from their coordinates — and a merged cell, a wrapped line or a right-aligned number defeats the guess. Multi-column layouts are the same problem rotated: reading order across two columns is a judgement about page geometry, not a fact in the file. Both come out as ordinary lines here, because a plausible-looking wrong table is worse than obviously flat text.
Why people convert PDFs to Markdown now
Mostly to feed a language model. A PDF cannot be pasted into a prompt usefully, and its structure is exactly what a retrieval pipeline needs to chunk sensibly — headings mark boundaries, paragraphs mark units. Markdown is the format that carries that structure in the fewest tokens. The rest is ordinary document work: moving a report into a wiki, extracting a specification into a repository, quoting a paper.
Reading the confidence figure
Good means every page produced text. Partial means some pages were empty, which usually indicates scanned inserts or full-page images among ordinary pages, and the missing pages are simply absent from the output. None means no page had any text at all. That last one is a statement about your file rather than about the conversion, and no setting on this page will change it.
Open it, read the confidence, then the Markdown
- 01Choose a PDF. Large documents take a moment — extraction is a page at a time, and the status line counts them.
- 02Read the confidence figure first. If it says none, the file is a scan and nothing below will help; if partial, some pages are missing from the output.
- 03Check the headings count against what you expected. Zero on a structured document means the source used no size hierarchy, so nothing could be inferred.
- 04Turn off "join wrapped lines" if the document is verse, code, or anything where the original line breaks carry meaning.
A report that has to go into a wiki
Headings set larger than the body are promoted, paragraphs are rejoined, and the result pastes into any Markdown editor.
QUARTERLY REVIEW (18pt) Revenue grew by nine per… (11pt)
## QUARTERLY REVIEW Revenue grew by nine per…
A scanned contract that returns nothing
The page is a photograph. Selecting text in a viewer highlights nothing, and extraction is correctly empty — the characters were never in the file.
contract-signed.pdf — 4 pages
Confidence: none 0 of 4 pages contained text. This needs OCR, not a converter.
A paper being prepared for a model
Structure is what a retrieval pipeline chunks on, and Markdown carries it in far fewer tokens than the PDF ever could.
a 40-page PDF
## Method We sampled … ## Results The effect was …
A document with no size hierarchy
Everything is set at one size, so there is nothing to infer a heading from. The output is flat and the report says why rather than guessing.
every line at 11pt
0 headings inferred. A PDF does not record headings — they are guessed from size.
What survives the trip, and how reliably
| In the PDF | In the Markdown | How it is decided |
|---|---|---|
| Text set larger than the body | A heading | Measured against the most common size in the document. An inference, not a fact. |
| Lines separated by a gap | A paragraph break | Inferred from vertical distance relative to the line height. |
| A line beginning with a bullet glyph | A list item | Recognised from the character — •, ·, ▪, ◦ and the plain hyphen. |
| A line beginning with a small number | A numbered item | Only one or two digits. 2024. is treated as a year, not the 2,024th item. |
| Bold and italic type | Lost | Weight and slant live in the font, and PDF.js reports the font rather than the intent. |
| Tables | Flattened | There are no cells in a PDF, only positioned text. A guessed table would look right and be wrong. |
| Two-column layouts | Interleaved | Reading order across columns is a judgement about geometry, not something the file records. |
| A scanned page | Nothing | It is an image. There are no characters to find, and this does not do OCR. |
Only the first four rows are conversions. The last four are limits of the format itself, and no converter — including the ones that do not mention it — handles them reliably.
Getting a usable result
- Test for a text layer before anything else: open the PDF and try to select a sentence. If nothing highlights, you need OCR rather than a converter.
- Expect to delete running headers and page numbers. They repeat on every page and a PDF gives no way to know they are furniture rather than content.
- Convert the pages you need rather than a whole book. Inference errors accumulate, and reviewing forty pages of guessed structure is slower than converting four.
- Turn off line joining for verse, code listings and addresses, where the original breaks are the content.
- If tables matter, copy them separately. Anything that flattens a table into prose has lost the relationship between the numbers and their labels.
What this cannot do
It cannot read a scan
No text layer means no characters. Optical character recognition is a separate technology with its own error rate, and pretending to do it would be worse than declining.
It cannot recover a table
A PDF has no cells. Reconstructing a grid from coordinates works until a cell wraps, merges or right-aligns, and a table that looks right while being wrong is the worst possible output.
Headings are inference, not fact
A document whose author used bold rather than size for headings produces none, and one with a large pull quote may produce a heading that is not one. The count is shown so the guess can be checked.
Reading order is the generator’s, not the page’s
Items come out in roughly the order the producing program emitted them, sorted by position. For a simple report that matches how you read; for a magazine layout it may not.
Extraction, inference and limits
- Extraction
- PDF.js, the renderer Firefox uses to display PDFs. Text items arrive with their coordinates and heights; nothing about structure comes with them, because the format has none to give.
- Body size
- The most common text height weighted by character count — the mode rather than the mean, so a large title and a page of footnotes do not drag it to a value matching neither.
- Heading rule
- Text at 1.2 times the body size or more becomes a heading; 1.8 times or more becomes the top level. Two levels only, because deeper ones would invent precision the source does not contain.
- Paragraphs
- A vertical gap wider than 1.8 line heights ends a paragraph. Wrapped lines are rejoined unless line joining is turned off.
- Not attempted
- No OCR, no table reconstruction, no column detection, no bold or italic recovery, and no image extraction.
- Limits
- PDFs up to 25 MB. Larger documents are better handled by a tool that can stream them.
- Engine loading
- The PDF reader is fetched from this site the first time you convert something, not on page load — it is a large dependency and most visitors never need it. So the no-network claim below holds for the conversion itself and for every later use, but the very first conversion needs the page to reach this origin once.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about converting PDFs
Why did my PDF produce no text at all?
Because it is a scan. A page produced by a scanner or a camera is an image wrapped in PDF packaging, with no characters in it to extract. Open it in a viewer and try to select a sentence — if nothing highlights, there is nothing to convert, and you need optical character recognition rather than a converter.
Can this do OCR?
No. OCR is image recognition with its own accuracy trade-offs and its own tooling, and bolting a weak version onto a text extractor would produce plausible-looking mistakes. The page tells you when OCR is what you need instead of guessing at it.
Why are my tables broken?
Because a PDF does not contain tables. It contains text positioned in a grid, and sometimes lines drawn nearby. Rebuilding a table means guessing column boundaries from coordinates, which fails on merged cells, wrapped text and right-aligned numbers. Flat lines are the honest output; a plausible wrong table is not.
How does it know what a heading is?
It measures the most common type size in the document, treats that as body text, and promotes anything noticeably larger. That is an inference from typography rather than something the file records, which is why the number of headings found is shown — so you can see whether the guess matched the document.
Why is the text out of order?
Items are extracted in the order the producing program emitted them and then sorted by position on the page. For a single-column report that matches reading order. For a magazine layout, a form, or anything with sidebars, the file simply does not record which order a human would use.
Are bold and italic preserved?
No. Weight and slant are properties of the font a glyph is drawn with, and extraction reports the text rather than the intent behind it. Headings survive because size is measurable; emphasis does not.
Is my PDF uploaded anywhere?
No, and this is the tool where that matters most — PDFs are usually contracts, statements and reports. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.
Why convert a PDF to Markdown rather than to text?
Because structure is worth keeping. Headings mark where a document divides, which is exactly what a retrieval pipeline chunks on and what a person needs to navigate a long file. Plain text discards that; Markdown keeps it in a form both a human and a model can read.