PDF to Markdown, text layer and all

Almost certainly because it is a scan: the pages are photographs or fax images of text, and the characters exist only as pixels, with no text layer for anything to read. This page detects that case and says so rather than handing back an empty box — it reports which pages hold an image and no text, and a document where every page is like that gets told plainly that it needs OCR. You can check the same thing in any PDF viewer: try to select a line of text with the mouse, and if nothing highlights there is no text layer. The other, rarer cause is a file whose content streams use a compression filter this reader does not implement, which is named in the warnings instead.

Because lines are grouped by their vertical position, and on a two-column layout the first line of the left column and the first line of the right column share one. A PDF stores no reading order — it stores glyphs at coordinates — so a converter either guesses at column boundaries or reads across the page, and reading across is the failure that is obvious rather than the one that silently drops half a sentence. For a two-column paper, converting one column's page range at a time does not help either; the practical answer is to fix the result by hand, or to get the document from its source format.

Because a table in a PDF is usually not a table — it is text positioned in columns, sometimes with lines drawn around it as separate graphics that have no connection to the words. Rebuilding cell boundaries from x coordinates works on a clean grid and fails badly on merged cells, wrapped values and right-aligned numbers, and a wrong table is worse than an honest paragraph, so this converter does not attempt it. Rows come through as lines with their cells separated by spaces, which is usually enough to paste into the Markdown table generator and fix in a grid.

No. A file with an /Encrypt dictionary has its streams scrambled with a key derived from a password, and this page refuses it with a clear message rather than half-decoding it. That includes the common case of a PDF with an empty owner password and no user password, which technically anyone can open — the encryption is still real and the key computation is deliberately not implemented here. Remove the protection in the application that created the file, then convert the result.

Because a PDF stores glyph codes, not characters, and the map back to Unicode is optional. When a font ships a /ToUnicode map — most do — every code resolves exactly. When it does not, this reader falls back to the font's encoding, handling WinAnsi, MacRoman and a /Differences array of glyph names, which covers ordinary Latin text. What is left over is genuinely unrecoverable: a subset font with no map and non-standard glyph names, and symbol fonts such as Wingdings, where the code for a tick mark is also the code for a letter. Any font in that state is named in the report above the output, so a gap is explained rather than mysterious.

By type size, ranked against the body of the document. The most common size across all pages, weighted by how much text is set in it, is taken as body text; every distinct size noticeably larger than that is collected, sorted from largest down, and mapped to # then ## then ### in order. A short, bold, isolated line at body size is treated as one level deeper, which is how most reports mark subsections. It is a heuristic and it can be wrong in both directions — a pull quote set large becomes a heading, and a document typeset at one size throughout gets none — which is why the tick box turns the whole inference off.

No, and there is nowhere for it to go: this site is static files on a CDN with no server that accepts an upload. The file is read with the FileReader API, decompressed with the browser's own DecompressionStream, and parsed by JavaScript in your tab — a contract you can verify by opening the network panel while converting, or by switching off your connection first and watching it still work.