A Link Extractor pulls every PDF href out of pasted HTML source and returns one URL per line, with duplicates merged and executable schemes dropped, entirely in your browser. When the task is to extract a link to a PDF, the work happens in the page source — the actual web address hiding inside an anchor tag, an area element, or a link element — not in the rendered page. Most readers searching this phrase have a saved HTML file, a public web page they can view source on, or a CMS export, and they want a clean list of every PDF destination without manually scanning lines of markup. The Link Extractor handles that task in three movements: it scans the three link-bearing start tags for href attributes, decodes the entity references that commonly appear inside URLs, then normalizes the values against an optional base URL so relative paths become absolute addresses. Nothing leaves the browser. The tool does not request any of the URLs it returns, which is the right behavior for an audit pass that should not touch third-party servers or trigger privacy concerns. The result is an inventory you can paste into a spreadsheet, a crawler, or a redirect checker for the next stage of review.
What the Tool Actually Does to PDF Links
When you ask the extractor to read an HTML page, it walks the source looking for href attributes on three specific start tags: anchor (a), area, and link. That matters for PDF discovery because PDFs are not only linked through ordinary anchor tags. A link element with rel="alternate" in the document head can point to a PDF version of the article; an area element inside an image map can route a click region to a downloadable brochure. By scanning all three element types, the tool builds a full source inventory rather than a partial one.
The parser also decodes a bounded set of HTML character references inside href values: decimal and hexadecimal numeric forms, plus the named entities amp, quot, apos, lt, and gt. PDF URLs often include ampersands inside query parameters, and an ampersand inside an attribute value is canonically written as the named entity in source. Decoding that named entity back to a literal ampersand produces the actual web address the browser would use. The implementation is intentionally not a full HTML entity database — rare named references stay encoded, which is preferable to silently applying a guessed table.
After decoding, the extractor normalizes the targets. Absolute HTTP, HTTPS, mailto, and tel values pass through directly. Root-relative, path-relative, parent-relative, and scheme-relative values resolve against an optional base URL using the browser URL model. Two identical relative links that point to the same absolute PDF become a single entry after normalization. Mail and telephone targets are kept because they are legitimate link destinations even though they are not web pages. The first-seen order is preserved, which is useful when you want to compare the extractor output against the order links appear in source.
Before You Paste: Things to Check in the HTML
The extractor operates on text you provide. Before you paste, three conditions control what the tool can find.
First, the source must come from a page you are authorized to inspect. The tool cannot fetch a remote URL because arbitrary cross-origin requests are often blocked and silently contacting pasted links would create privacy and security problems. Copy the page source through the browser's "View Source" action, save a CMS export, or run your own authorized crawler. The extractor does not log or transmit anything you paste, but the legal obligation to access the source stays with you.
Second, the input is capped at 200,000 characters to keep the interactive scan bounded. A typical product page sits well below that limit. Very long documents should be split or handled with a controlled crawler.
Third, the tool removes comments and common raw-text containers — script, style, textarea, title, iframe, noembed, and noframes — before scanning. That prevents strings that merely look like anchor markup inside JavaScript or literal text from becoming false links. The trade-off is that the extractor is a source parser, not a full browser HTML tree builder. Severely malformed markup, unusual unquoted attributes, or missing raw-text closing tags can produce a different result from the bounded scan. The interface states that limitation, and for legal, security, or migration audits it is worth comparing the extractor output against a browser DOM export and a real crawler rather than trusting one channel.
Extract a Link to a PDF in Three Steps
- Open the Link Extractor, paste the authorized HTML source into the input field, and (if the page uses relative paths) enter the absolute page URL into the optional base field. The base must use HTTP or HTTPS and cannot contain credentials; this prevents a misleading resolution context and keeps user information from being copied into every resolved result.
- Run the extract. The tool returns one URL per line together with three counts: unique targets kept, duplicates removed during normalization, and skipped entries (empty values, same-document fragments, executable schemes, invalid URLs).
- Copy the result for your authorized crawl or audit. Verify status, redirects, and rel meaning with the tools that exist for those jobs. The list itself is an inventory, not a health report.
A worked example shows what the base URL actually changes. If the source contains <a href="/downloads/report.pdf"> and the base field holds https://example.com/products/page, the extractor resolves the path to https://example.com/downloads/report.pdf. Without a base, the output stays relative so the tool does not invent a host. The same logic applies to a parent-relative value such as ../files/briefing.pdf, which resolves against the directory of the base URL, not against the document root.
What Counts as a PDF Link, and What Gets Skipped
The extractor returns or skips each candidate on transparent rules, and the skipped count tells you how many entries were filtered out. The table below maps the common PDF scenarios you will see in page source to the behavior you can expect.
| Scenario in source | What the extractor returns | Why |
|---|---|---|
| <a href="/whitepaper.pdf"> with base https://example.com/ | https://example.com/whitepaper.pdf | Root-relative resolved through the base |
| <a href="https://cdn.example.com/report.pdf"> | https://cdn.example.com/report.pdf | Absolute URL passed through |
| <a href="../files/briefing.pdf"> with base | Resolved absolute against base directory | Parent-relative handled by browser URL model |
| <a href="javascript:openPdf('x')"> | Skipped (counted) | Executable scheme filtered |
| <a href=""> empty target | Skipped (counted) | Empty href dropped |
| <a href="#download"> same-page fragment | Skipped (counted) | Not a PDF destination |
| <link rel="alternate" href="/guide.pdf"> in head | Included | Link element scanned alongside anchors |
| Two identical absolute PDF hrefs | One entry | Deduplication after normalization |
| <a href="mailto:[email protected]?subject=PDF"> | Retained as mailto:... | Legitimate non-web destination |
If your output looks shorter than the page contains links, the skipped count is the first place to look. A high skipped value is not a bug; it is a record of the filtering decision so an apparently short list does not hide it.
After the Extract: Verify the PDF Targets
The list the extractor returns is an inventory. A listed PDF may redirect, return an error, require authentication, be blocked by robots controls, or intentionally point off-site. The extractor does not label internal versus external links, test HTTP status, evaluate rel attributes, or decide SEO quality. Those questions are downstream.
For a full audit pass, pair the inventory with a crawler you control. A broader page-level URL audit uses the same pattern at larger scope — paste the source, review the counts, copy the list — and is covered in the extract all URLs from page source for SEO audits workflow. For PDF-specific verification, confirm that each target still resolves, returns a 200 status, and serves application/pdf. Watch for redirect chains: a link that points to https://example.com/old-report.pdf may land on a 301 to a new path, and the extractor lists the original href, not the final destination.
If the page declares a link element with rel="canonical" pointing to the PDF URL itself, that is a signal the PDF is the canonical resource rather than the HTML page. Treat the rel attribute as evidence, not a verdict. The extractor intentionally does not infer whether a target is navigational, canonical, preload, stylesheet, or another relationship.
When PDF Targets Are Missing From the Output
Several recurring patterns cause PDF targets to vanish from the extracted list, and recognizing them saves a second pass.
Dynamic PDF buttons inserted by JavaScript are the most common cause. The extractor reads static source. If the HTML shipped to the browser contains <button id="download"> and a script attaches the PDF URL on click, the source will not contain the href. Open the page in a real browser, trigger the script, then export the rendered DOM to find those links.
PDFs embedded through iframe, object, or embed elements use a src attribute, not an href. The extractor scans href values on anchor, area, and link only. An iframe whose src is /viewer.pdf will not appear in the output. This is a deliberate scope choice, because the tool's job is source inventory for link targets, not media discovery. Look at the parent element or the surrounding anchor wrapper for the actual download link.
Same-document fragments are dropped by design. If a PDF is linked as <a href="#appendix">, the target is a section anchor on the same page, not a downloadable file. The extractor keeps the rule that fragments do not name an external resource.
Severely malformed markup can change the result. Unquoted attributes, missing raw-text closing tags, or unusual nesting can shift how the bounded scan reads the document. When in doubt, compare against a browser DOM export or a real crawler for the high-stakes decisions.
Related reading: HTML Meta Tags Generator: Build a Clean Basic Block.