Structure first, text second
There is already a good tool for pulling the words out of a PDF, and this isn't it — that's the sibling PDF to text converter, which gives you the full text layer to copy, edit and export. This page answers a different question. Not "what does this document say" but "how is this document built, and where is the part I need?"
That distinction matters most on documents you are not going to read in full, which is most long documents. When you are assessing whether a paper is relevant, the section list plus a sentence from each section is usually enough to decide. When you are returning to a report you skimmed a month ago, the map is what you actually remember it by. Extracting 40,000 words of body text serves neither case; it just moves the scrolling problem somewhere else.
How a PDF's structure is actually found
There are two ways to get a document's outline out of a PDF, and this tool tells you which one it used, because they are not equally trustworthy. The first is the embedded outline — bookmarks, the collapsible tree your PDF viewer shows in its sidebar. When a document has one, it is authoritative: the author or the publishing pipeline declared that hierarchy, so the sections, their nesting and their page numbers are exact rather than inferred. Documents produced from LaTeX, Word with proper heading styles, InDesign or most publisher templates usually carry one.
The second is heading detection, used when no bookmarks exist. A PDF has no concept of "this line is a level-2 heading" — it stores glyphs positioned at sizes. So the fallback works the way you would by eye: it finds the size that sets most of the body text, treats anything meaningfully larger as a heading, treats short bold lines at body size as run-in headings, ranks the distinct heading sizes to infer nesting depth, and discards the running header that repeats on every page. It gets most academic and corporate documents broadly right, and it will still make mistakes — which is exactly why every node here is editable and deletable.
Reading a paper structurally
The standard advice for reading research — often credited to Keshav's three-pass method — is that the first pass is not reading at all. You look at the title, abstract, section headings and conclusions, and decide whether there will be a second pass. Most papers should not get one. The bottleneck in a literature review is rarely comprehension; it is triage, and triage runs on structure.
A generated outline makes that first pass concrete rather than a discipline you have to maintain. You see the section list at once, with a line of each section's opening prose attached, and you decide from there: this paper's method section is the only part I need, this one's related work is a reading list in itself, this one can go. Deleting the irrelevant sections before you save is part of the exercise — what remains is the note you actually wanted, not a copy of the paper.
Why a spatial map beats linear notes for synthesis
Reading one source linearly and taking linear notes works fine. Synthesizing twelve of them does not, because the thing you are trying to build — how these sources agree, contradict each other, and stack up into an argument — is a set of relationships between documents, and a stack of separate linear documents is the one format that hides relationships. You end up scrolling between notes trying to hold the comparison in your head.
Laying the sections out spatially removes that constraint. Two papers' method sections can sit side by side; a contradiction can be marked with an arrow between the two claims rather than a parenthetical in a paragraph; a cluster that keeps growing tells you where the real theme of your review is, without you having to name it in advance. This is the same reason literature-review matrices exist on paper — a map gives you a persistent visible structure to think against instead of reconstructing it every session.
That is what the "Save to my canvas" hand-off is for: each top-level section becomes a column of its own subsections on an infinite canvas, so you can drop a second paper's outline next to the first and start drawing the connections between them.
What it can and cannot extract
It extracts headings, their nesting, the page each one starts on, and the prose that immediately follows each heading up to the next one. It does not extract figures, tables, equations, footnotes or citations, and the excerpt is a literal slice of the document's own words — nothing is summarized, rewritten or generated. What you see under a heading is what the document says there.
Some layouts are genuinely hard. Two-column academic formats interleave columns in the text layer, so an excerpt can pick up a line from the neighbouring column. Slide decks exported to PDF often use one size throughout and produce no hierarchy. Documents with decorative pull quotes set large will occasionally offer them up as headings. In every one of these cases the fix is the same and takes seconds: delete the wrong nodes, fix the wording, keep the rest.
Why scanned PDFs behave differently
A PDF is a container, and what's inside it varies more than the extension suggests. A document exported from a word processor contains real text — characters, fonts, positions — which is why you can select a sentence in it. A scanned document contains a photograph of a page: pixels arranged to look like letters, with no characters anywhere in the file. Your eyes cannot tell the two apart; software immediately can.
There is no structure to find in the second kind, because there is no text at all — no bookmarks, no headings, no font sizes to compare. So this tool checks for a text layer up front, and when a file comes back with essentially no characters it says so and points you to the image-to-text tool, which uses OCR to recognize letters in a picture. That is a different technique for a different problem, and running it first gives you text you can then structure. An empty outline with no explanation would be worse than useless — it would look like your document has no sections.
Long documents, and what happens on your device
Because parsing happens locally, a long document costs your CPU rather than a queue on someone's server. A few hundred pages takes seconds, and the tool shows page-by-page progress and stays cancellable while it works instead of freezing the tab. Files up to 40 MB are supported, the first 500 pages are read, and the map is capped at a few hundred sections — past that point a map stops being a map.
Nothing about the file is transmitted. The PDF is read from disk into the page, parsed there, and discarded when you close the tab. The only thing that ever leaves your browser is an outline you explicitly choose to save to your canvas — the Markdown export and the on-screen map need no account and involve no network at all.