Drop a PDF and get Markdown back. It is read in this browser — the file is never uploaded.
Drop a .pdf here — it is read in this browser and never uploaded.
Drop a PDF and the text comes back as Markdown: headings as headings, bullets as bullets, and paragraphs rejoined into paragraphs. That last one is the difference between output a model reads well and output it does not — a PDF stores one line at a time, so a naive extraction returns a sentence broken across six lines, and words hyphenated at the margin come back as "gener- ated".
Running headers and page numbers are stripped by default. On a forty-page report that is forty copies of the company name and forty "Page n of 40" lines, which is pure noise in a prompt and, on a metered model, noise you pay for. The panel says how many lines it removed, and a checkbox puts them back if you wanted them.
The reason to convert at all is that Markdown is much cheaper to read than a PDF. A PDF handed to a model either goes through the model's own extraction — which you cannot see or correct — or is processed as page images, which costs far more for the same words. Markdown is the format you can look at before you send it, which means you can tell when it went wrong.
Everything happens in this tab. The file is read with your browser's own file API, parsed here by pdf.js, and turned into Markdown here. There is no upload, no server round-trip, and nothing written down — which matters mostly when the PDF is not yours to hand to a converter site in the first place.
The output is yours to take: copy it, or download a .md file. If you want to read it as a page rather than raw text, the Markdown viewer opens it, and if the thing you build from it needs to reach a client, that is a separate step you take on purpose.
Two reasons, and the second is the one people find out about later. First, cost and length: the same words cost far less as text than as a PDF a model has to process as page images. Second, control: when you hand over a PDF, whatever extraction happens is invisible to you, so if it reads a two-column page in the wrong order you have no way of knowing — you just get a confident answer built on scrambled text. Markdown is the version you can read before you send it.
No. Your browser reads the file, pdf.js parses it in this tab, and the Markdown is assembled here. Your document is never sent anywhere, never stored, and never logged, and closing the tab leaves nothing behind. To be exact about what the page does do: like any web page it loads its own code from miinideck, and for a document in Chinese, Japanese or Korean it fetches the character-map files needed to decode those glyphs — so the fact that you opened a CJK document is visible in that request, while nothing of its contents ever is. That is the whole reason this tool has the shape it has: the documents people most want to convert — a client's contract, an internal report — are exactly the ones they should not be dropping into a converter site.
Not as tables. A PDF does not record "this is a table" — it records where each piece of text sits on the page, and a grid has to be inferred from that. Inference gets it wrong often enough that we would rather give you plain text you can see is plain than a table that looks authoritative and has two columns swapped. For table-heavy documents, Marker and MarkItDown are built for exactly that job and run locally too.
It is almost certainly a scan — a photograph or scanner image of a page, wrapped in a PDF. There are no characters in the file, only pixels that look like characters, so there is nothing for any text extractor to find. Turning that into text needs OCR: Acrobat and ABBYY FineReader do it, and uploading the PDF to Google Drive and opening it with Google Docs does it for free. Bring the result back here if you still want Markdown.
They are removed on purpose. A line that appears at the top or bottom of most pages is chrome rather than content, and on a long report it repeats dozens of times — noise in a prompt, and length you pay for on a metered model. The panel tells you how many lines it took out, and the "keep headers and page numbers" checkbox restores them.
Yes. CJK text needs the character maps that tell the reader which glyph is which character, and those ship with this page — without them a Chinese PDF extracts as blank or as rows of identical boxes, which is the failure most browser-based converters have.
Up to 30 MB, and the limit exists because the work happens in your browser rather than on a server. A several-hundred-page document will take a moment and show you which page it is on. Beyond that ceiling the honest answer is to split the file, because a tab that runs out of memory fails in a much less useful way than a message.
Usually, yes, and for a specific reason: headings and lists tell a model how the document is organised, so it can tell a section title from a sentence and an enumerated list from prose. Flattening everything to plain text throws that away, and it is information the PDF actually contained. It costs almost nothing in length — a few hash marks and hyphens.
Not from here — this page converts and hands the file back, and that is where it stops. When what you build from it needs to reach a client, miinideck publishes a page at an unguessable link that stays out of search by default. Without an account the link lasts 7 days and has no password; sign in (free) to add a password or set your own expiry. That involves a real upload, so it only happens when you ask for it.