How a PDF becomes Markdown on your own device
Last reviewed
Most converters answer the privacy question with a promise: we delete your file afterwards. This one answers it with an absence — there is no upload, so there is nothing to delete and no retention period to take on trust. That claim is only worth something if you can check it.
So this is the mechanism rather than the reassurance. The short version is set out on the page about keeping a PDF off a server; this is the long version, with the inconvenient parts left in.
7 minute read
What happens when you drop a file
Nothing moves. The browser hands the page a reference to a file on your disk, and every step below runs against that reference inside the tab you already have open. The cheap checks come first, which is why picking the wrong file gives you an error immediately rather than after a progress bar.
| 1. Checked | Name, type and size are inspected before any parser is fetched and before a byte is read |
|---|---|
| 2. Read | The bytes are pulled into memory with the File API, as an ArrayBuffer — a read from your own disk |
| 3. Sniffed | The first kilobyte is checked for a PDF, ZIP or OLE2 signature. Bytes overrule the filename |
| 4. Parsed | PDF.js opens the document in a dedicated Web Worker, returning per page the text fragments with their coordinates, font and size |
| 5. Inferred | Those coordinates become structure, measured against the document's own body-text height |
| 6. Rendered | The structure becomes GitHub Flavored Markdown in a textarea, in the tab and nowhere else |
Why the file never leaves your device
Parsing runs in a Web Worker — a second JavaScript thread with no access to the page. That keeps the tab responsive during what is otherwise seconds of solid computation, and it makes the privacy claim checkable rather than rhetorical.
A worker is started from a URL, and that URL is on this site's own domain rather than a CDN — as are the character maps needed for non-Latin encodings and the standard font metrics. A conversion asks nothing of any third party, so there is no third-party request in which a document could be hiding.
You do not have to take that on faith. Your browser will tell you, and it takes about a minute:
- Open the converter, then developer tools — F12 on Windows and Linux, Command-Option-I on a Mac.
- Select the Network tab, tick 'Preserve log', leave the filter on All, then clear the list with the circle-and-slash button so you see only what the conversion does.
- Drop in a PDF and wait for the Markdown to appear.
- Read the list: the PDF.js bundle, the worker script, sometimes character maps or font data — every one of them a GET from this domain, and identical whichever file you picked.
- Check the Method column. An upload is a POST or PUT carrying a body about the size of your document. There is not one — the largest entry is the parser arriving, not your document leaving.
What the page does load
The page is not silent, it is just not sending your document. Loading it needs the network, and depending on your consent choices, analytics may fire a page-view event carrying a URL and a page title — which the request for the page already revealed.
The conversion code itself contains no analytics: no event when a conversion starts, none when it finishes, nothing reporting a filename, a page count or a size. The distinction is between a page that makes requests, which this one does, and a page that makes requests about your document, which this one does not.
Why there is a page limit
There is a cap on pages per conversion and a cap on file size, both enforced in your browser before the file is read. The current numbers are printed on the converter itself rather than here: they are an administrative setting, and a number copied into an article goes stale silently.
The reason is not cost, since nothing is billed per page. Your tab has finite memory, and a conversion has a hard timeout after which the run is abandoned rather than left to spin. A thousand-page PDF parsed in a browser tab is not a slow conversion, it is a crashed one — and a cap that refuses the job beats a tab that dies holding your document.
If you are hitting the cap on a genuinely long document, split it before converting. The guide on theses and long reports covers where to cut and why chapter boundaries beat arbitrary ones.
Scanned PDFs, and why they are the exception
Everything above depends on the PDF having a text layer — real character codes at real coordinates. A scan has none. It is an image per page, and walking the text layer of an image finds nothing.
There is no recognition step in your browser, so a scanned file does not fail with an error; it succeeds and returns almost nothing. The converter notices by counting characters: a document whose whole text layer yields fewer than twenty characters is treated as image-only and says so, rather than handing back an empty file.
That threshold is deliberately low, with a consequence worth knowing: a document that is half digital and half scanned will not trip it. It converts as a text document and the scanned pages come back blank, unflagged. If a conversion is suspiciously short, count which pages produced nothing.
Recognising a scan needs a real OCR engine and more processing than a tab can do, so it runs on a server, on a separate converter for scanned documents, behind a consent step naming the page count and the destination before anything moves. That is a genuine upload and it is described as one. Worth reading first: what recognition can and cannot recover — handwriting does not survive it, and a phone photograph survives it badly.
What converts well, and what does not
A PDF stores glyphs at coordinates. The structure that produced the layout was used to compute those positions and then thrown away, so reconstructing it is inference, not extraction. What follows is this converter's real behaviour, losses included.
One conclusion is worth drawing early: if the document began in Word and you can get the .docx, convert that instead. The Word converter reads structure the file states outright, so headings, links and strikethrough survive — the comparison between the two sources is blunt about the difference.
| Headings | Inferred from size relative to the document's own body text, so a heading set in bold at body size reads as a paragraph |
|---|---|
| Paragraphs and lists | Reliable. Lines group by shared baseline and split at a vertical gap; markers are recognised and nesting comes from indentation |
| Tables | Detection never spans a page break, one visual line is one row, and the first row always becomes the header — so a repair pass is normal |
| Two columns | Split by finding a vertical gutter, but it needs a long run of lines on both sides — a short two-column block is not split and will interleave |
| Bold, italic, code | Inferred from the font's PostScript name. Reliable for conventionally named fonts, silent for unusual ones |
| Links | Lost. A PDF stores a hyperlink as an annotation over the text, and only the text layer is read |
| Images | Dropped, and not counted. Extraction never looks at the drawing operations, so a conversion cannot tell you how many it lost |
| Footnotes and equations | Neither is reconstructed. A superscript marker is just a character at a coordinate, and positioned mathematics returns as scrambled text |
Questions people ask
| Does the file get uploaded if the conversion fails? | No. There is no upload path in the converter, so nothing a failure could trigger. An error means the parser refused the bytes; the bytes stayed where they were |
|---|---|
| Can you see what I converted? | No — not as policy but because no request would carry it. The conversion code fires no analytics events, so not even the fact that a conversion happened is reported |
| Is a password-protected PDF supported? | Yes. The converter asks for the password and passes it to the parser in the tab. It opens the document locally and is not transmitted, for the same reason the document is not |