PDF Link Extractor is a browser-based utility that lists every clickable link annotation inside a single PDF, groups them by page and annotation number, and lets you copy the result or download it as a UTF-8 TXT or a formula-neutralized CSV — and the practical way to "extract links from PDF multiple files at once" with it is to run the same one-file workflow across each document in turn, because the file never leaves your device, no account is required, and the whole cycle of choose, extract, copy, download takes a small number of seconds per document when the PDF is well-formed and under the 25 MiB / 40-page ceiling. Each pass produces its own report, so the resulting files can be sorted, diffed, or merged in a spreadsheet afterward if you need one combined view across many PDFs. This article walks through that repeated workflow, explains what the report actually contains, and clarifies the limits so a multi-file job does not stall on a rejected document.

What "multiple files at once" means with this tool
The keyword phrase suggests a batch upload, but the extractor is designed around a single, bounded local file per session. That design choice is deliberate: PDF.js loads only after you press the button, stays outside the initial page bundle, and shares a fixed worker URL with the other PDF.js tools. A replacement job cancels the earlier one and tears down page references, loading tasks, and download URLs. The benefit for someone with ten, fifty, or a hundred PDFs is that nothing is uploaded, nothing is queued on a server, and there is no risk of one bad file poisoning the rest of a batch — each file is judged on its own merits against the 25 MiB / 40-page budget and the encryption / damage checks. In practice, "at once" becomes a matter of repeating the same steps for each file and then combining the per-file reports.
For readers whose folders contain dozens of PDFs, this approach scales because the tool is local and the report is inert. You can run extraction on one file, copy the text report, paste it into a master document, move to the next file, and repeat. Once every file is processed, the combined report preserves the original page labels per file so each PDF's link list remains auditable on its own. If you would rather keep the files separate, the per-file CSV or TXT download is the cleaner option and makes downstream merging in a spreadsheet trivial.
What the tool actually reads inside a PDF
Many readers expect a URL searcher that scans every word on every page and flags anything that looks like a web address. That is not what this tool does, and the distinction is the reason its output has so few false positives. The extractor requests PDF.js page annotations and selects only entries that are real link annotations, including supported external URLs and the named or explicit internal destinations that PDF.js exposes. Visible text that merely contains a URL — for example a printed footnote, a font glyph that looks like a slash, or a metadata stream — is not a link annotation, so it is not included in the report.
The Mozilla PDF.js project documents the getAnnotations method on PDFPageProxy as the way to enumerate annotation data per page, and the tool relies on that interface rather than regex-matching raw PDF bytes. This avoids confusion with compressed object streams, embedded font tables, and ordinary body text. A URL printed as plain text but never made clickable by the PDF producer may be missing from the report, which is the expected behavior rather than a bug. The report only proves that PDF.js saw a supported link annotation on that page — not that every visible URL has been cataloged.
Run the extraction for one PDF
- Open PDF Link Extractor in your browser and choose the local PDF you want to process. The file is read locally; nothing is uploaded to a link-analysis server.
- Confirm the file is under 25 MiB and under 40 pages. Encrypted, malformed, unsupported, or over-limit PDFs return a visible error before extraction starts, so fix or split them first.
- Click Extract Links. PDF.js and its shared worker load on demand and inspect link annotations in page and annotation order.
- Review the results. Each entry shows the page number, annotation number, link type, and target. Unsafe schemes such as javascript, data, file, and blob are skipped rather than displayed as clickable.
- Copy the plain-text report, or download a UTF-8 TXT or a formula-safe CSV. CSV cells that begin with spreadsheet formula prefixes are neutralized, and quotes and line breaks are escaped using CSV rules so the file opens cleanly in spreadsheet software.
Repeat the workflow across multiple files
For a multi-file job, treat each PDF as an independent run. The extractor does not maintain a session list, and replacing the loaded document cancels the previous run, so the simplest pattern is to finish one file — including the copy or download step — before opening the next. If your files are well under the limits, this is fast enough that "multiple files at once" is a matter of cycling through them in a few seconds per cycle. If a file fails the 25 MiB or 40-page check, split it first using the Split PDF tool or extract specific page ranges with Extract PDF Pages, then re-run extraction on the parts that fit.
When you need to combine results from many files, the CSV download is usually the easiest to merge because every entry is a row with stable columns. Open the per-file CSVs in a spreadsheet, append them to a master sheet, and add a column with the source filename so each link remains traceable back to its PDF. The TXT option is best when you want a human-readable archive per file, with stable page labels that survive copy-paste into a document or wiki. For large inventories that may push the per-file limits, the Extract Links From a Large PDF: File Size Limits guide explains where the thresholds come from and how to pre-trim oversized PDFs.
What the report contains and what it skips
The summary line at the top of each report records examined annotation counts, accepted links, duplicates, and skipped unsafe or unsupported targets, so you can tell at a glance whether anything was filtered out. Exact duplicate targets on the same page are removed, while a repeated link on a different page remains visible because the page occurrence is useful evidence in an inventory. Internal PDF destinations — named destinations or explicit destination arrays that point to another location in the same document — are labeled as internal and serialized in a bounded representation. The report does not promise a final page number for every internal destination, because destination structures and viewer behavior vary across documents.
| Target category | Example | Included in report? |
|---|---|---|
| Standard web link | https://example.com/report | Yes — listed with page and annotation number |
| Email link | mailto:[email protected] | Yes — accepted scheme |
| Phone link | tel:+15551234567 | Yes — accepted scheme |
| Internal jump | Named destination or explicit destination array | Yes — labeled as internal, representation is bounded |
| JavaScript URI | javascript:alert(1) | No — rejected as unsafe scheme |
| File or data URI | file:///etc/passwd, data:text/html;base64,... | No — rejected as unsafe scheme |
| Control-character URL | Targets containing control bytes | No — rejected during case-insensitive scheme check |
| Visible printed URL | Plain text on the page that is not a link annotation | No — not a PDF link annotation |
Safety properties that matter when processing many files
Because the extractor is meant for inventory and migration work, not for clicking, the report is rendered as inert text and the tool does not navigate to, validate, or reputation-check any of the targets. That is why even accepted http, https, mailto, and tel entries are shown as plain text: presence in the report only means the PDF producer embedded a link annotation. Treat each extracted target as untrusted data until you verify it independently, especially when the source PDF came from outside your organization.
Two more properties help when handling sensitive or compliance-bound documents. First, the source PDF and its targets stay on the device — there is no upload, no account, and no server-side queue. Second, the CSV output is sanitized for spreadsheet risk per the OWASP CSV Injection guidance: cells that begin with spreadsheet formula prefixes are neutralized, quotes and line breaks are escaped, and the same inert text is used when you copy to the clipboard. These properties make it reasonable to run the workflow across many files in a row, including PDFs that contain confidential internal jumps.
When this tool is and isn't the right fit
| Use case | Is this tool a fit? | Why |
|---|---|---|
| Build a link inventory from a set of PDFs | Yes | Reports are per file, in CSV or TXT, with page and annotation order preserved |
| Migration check across many documents | Yes | Internal destinations and external URLs are both reported, with stable page labels |
| Document QA review before publishing | Yes | You see exactly which destinations PDF.js exposes and can verify them externally |
| Broken-link or 404 checking | No | The tool does not fetch or validate targets |
| Phishing or malware scan | No | Unsafe schemes are skipped, and no reputation check is performed |
| Accessibility audit | No | Link annotations are listed, but alt text, structure, and tagging are out of scope |
| Full-text URL harvesting | No | Only link annotations are read, not every URL-shaped string in the text layer |
Limits to keep in mind for multi-file jobs
Each file is bounded at 25 MiB and 40 pages, with additional caps on annotation count, target length, and total report characters so one document cannot create unbounded work or output. Encrypted, damaged, unsupported, and over-limit PDFs return a visible error rather than a partial result, which is the safer behavior when you are processing a mixed folder. If a file is encrypted and you have the password, removing the password with Remove PDF Password produces an unprotected local copy that the extractor can then read. If a file is over 40 pages, split it with Split PDF and run extraction on each part.
For very large inventories, plan the order so well-formed files are processed first and any rejected files are triaged separately — that way the per-file cycle stays short and you can keep the original PDF unchanged as the source record. The extractor never modifies the input document, so you can re-run extraction on the same PDF at any time if the file is updated, and the original remains the authoritative source.
Related reading: PDF to Long Image Offline: Local PNG Workflow.