Extracting links from a PDF means reading the clickable link annotations that the file already stores alongside its text and images, then producing a page-ordered list of every supported URL and internal jump the document exposes. A browser-based extractor such as PDF Link Extractor does not scan visible text for URL-shaped strings; it walks the annotation objects using PDF.js, accepts only targets whose scheme is HTTP, HTTPS, mailto, or tel, and writes the result as inert text in a CSV or TXT report that stays on your device. Because the tool reads annotations rather than the visible text layer, a URL that was typed into the page but never made clickable will not appear, while a link that the author buried under an image, a shape, or a colored phrase will. Limits of 25 MiB and 40 pages, with no encryption or malformed input, keep the work bounded and predictable.
People often discover the difference the hard way. They highlight a URL on the page, copy it, and assume every link in the document works the same way. A PDF keeps two parallel worlds: the painted text you see and the annotation layer that defines which areas are interactive. The article that follows explains both — what the tool reads, what it skips, and what it cannot promise about the destinations it lists.
What "Extracting Links From a PDF" Actually Means
At its core, "extracting links from a PDF" is the act of listing every annotation in the file whose action is to follow a destination. Each link annotation carries at least two pieces of information: a placement (which rectangle on the page the link covers) and a target (where a viewer should go when the rectangle is clicked). The target can be a web URL using a small set of approved schemes, or it can be an internal destination that points to another page, a named location, or a specific coordinate inside the same document.
The tool turns that placement-and-target pair into a row in a report. It does not move, copy, or rewrite the original file. The PDF and the extracted targets remain on your device; the report is the only artifact the tool creates, and you can copy it as plain text or download it as a CSV or TXT file.
Link Annotations vs. Printed Text
This is the single biggest source of confusion when people try to extract links from a PDF, and it is worth pausing on it. A PDF page can carry a URL in two completely separate places: as visible text in the content stream, and as the target of a link annotation in the annotation array. Only the second one is a clickable link. The table below spells out the practical difference.
| Where the URL appears | Stored as a link annotation? | Included in the report? |
|---|---|---|
| Underlined phrase "https://example.com" typed as visible text | No | Not by default |
| Hyperlink placed over a logo image | Yes | Yes, with page number |
| A URL inside a form field's help text | Usually no | No |
| A mailto: address behind an "Email us" button | Yes | Yes |
| A javascript: link attached to a button | Yes, but unsafe scheme | Skipped |
| A URL hidden behind a colored shape covering a paragraph | Yes | Yes |
PDF Link Extractor reports only annotations, so the second, fourth, and sixth rows in the table above are the cases that produce a row in the output. The first row — a visible URL that was never made clickable — is the case that surprises users most. The tool does not guess; it works from PDF.js annotation data, which is why a printed URL is missing when it never became a link.
How the Extractor Reads the File
The engine is PDF.js, Mozilla's open-source PDF parser that runs in the browser. PDF Link Extractor loads the library only after you press the button, so the initial page bundle stays small and no parsing happens until you actually ask for a report. The shared worker that PDF.js uses is loaded from the same fixed URL the other PDF.js tools in the suite use, which keeps behavior consistent.
Once the library is ready, the tool asks PDF.js for the annotation array of each page in document order. It filters that array down to objects of subtype Link, then inspects each link's target field. Targets fall into two broad groups:
- External links that carry a URL with an approved scheme. The approved set is HTTP, HTTPS, mailto, and tel, checked case-insensitively and rejected if they contain control characters. Anything else — javascript:, data:, file:, blob:, vbscript:, and similar — is excluded from the report rather than displayed.
- Internal destinations that point somewhere else inside the same PDF. These may be a named destination string or an explicit destination array (a page reference plus coordinates or a fit mode). They do not always have a web URL, so the report labels them as internal targets and serializes a bounded, readable representation.
Skipped targets are summarized separately, never shown as clickable, and never followed. The full sequence — load the file on explicit user action, request annotations, filter by type and scheme, deduplicate within a page, enforce annotation and output budgets, serialize inert TXT and formula-neutralized CSV, and clean up loading tasks and download URLs on replacement — is the same methodology the tool documents.
Run the Extraction in Your Browser
Here is the concrete workflow. Each step maps to a button or a result on the page; nothing is uploaded to a server.
- Open PDF Link Extractor in your browser. The page is empty until you pick a file, so nothing runs in the background.
- Choose one local PDF using the file picker. The file must be at most 25 MiB and at most 40 pages, and it must not be encrypted, malformed, or otherwise unsupported. If any of those conditions fail, the tool returns a visible error and stops before reading the file.
- Click Extract Links. The tool loads PDF.js and its shared worker, then walks the annotation array of each page in order. The work happens in the browser; it is not sent anywhere.
- Review the report as it appears. Each row carries a page number, an annotation number, a type, and a target. External URLs, internal destinations, and skipped targets are grouped separately.
- Copy the plain-text report, or download a formula-safe CSV or a UTF-8 TXT file. The CSV is escaped and neutralized so that a target starting with =, +, -, or @ does not become a spreadsheet formula when you open it.
- If you start a new extraction, the previous run is cancelled. Loading tasks, download URLs, and transient state are cleaned up so the next file starts from a known empty state.
Reading the Report: External, Internal, and Skipped Targets
The CSV you download has four columns: page, annotation number, type, and target. The TXT version uses the same labels in a stable plain-text layout. Both versions list annotations in page order, then in the order PDF.js returned them within each page. Exact duplicates on the same page are removed; the same link repeated on a different page is kept, because seeing the same target appear on page 4 and page 11 is useful evidence of how the document references it.
Internal destinations do not always have a web URL. The report still includes them, but it labels them as internal and writes a bounded representation such as a named destination or a page reference. The tool does not claim to resolve every internal destination to a final page number, because destination structures vary between documents and viewers.
Skipped targets appear in a separate summary count rather than as rows. The summary also reports how many annotations were examined, how many were accepted, and how many duplicates were collapsed. That summary is what makes the report useful for inventory work: you can tell at a glance whether the page count of annotations matches the page count of accepted links, or whether most links were excluded as unsafe.
Safety and Privacy Boundaries of the Report
Three properties matter here. The first is where the file goes: nowhere. The PDF and the extracted targets stay on your device. The second is what the tool does with the targets: nothing. It does not navigate to, fetch, validate, or reputation-check any extracted destination. A target's presence in the report only says that PDF.js exposed a supported link annotation. The third is what an attacker could try to do with the exported file: a CSV cell that starts with =, +, -, or @ can be interpreted as a formula by spreadsheet software. The tool neutralizes those prefixes before serialization, escapes quotes and line breaks with CSV rules, and keeps the targets inert even after you open the report.
These boundaries also explain what the tool is not. It is not a broken-link checker, not a phishing detector, not an accessibility audit, and not a content scanner. If you need to know whether a destination is still live, whether it points to malware, or whether a link has accessible text, you have to verify those things separately. The report is the inventory; the verification is on you.
When to Use This Report, and When Not To
The report fits four jobs especially well. First, inventory: you want a list of every link a PDF points to, grouped by page, with no manual clicking. Second, migration checks: before you move a document into a new system, you want to know which links will need re-pointing. Third, document QA: you want to confirm that the links an author intended are actually present as annotations and not just as printed text. Fourth, reviewing where a PDF sends readers — useful for compliance, editorial review, and content audits.
The report does not replace independent verification. Treat the targets as untrusted data even though the file came from your own device. Spot-check important destinations before publishing or sharing the document. Keep the original PDF as the source of record, because the report is a derivative view of its annotation layer and not a substitute for the file itself.
Related reading: Extract PDF Pages for Printing Without Wasting Paper.
Related reading: How to Extract Links From a PDF for Beginners.