To extract all URLs from page source means scanning the HTML markup you copy from a browser's View Source action and pulling every href value out of anchor, area, and link start tags into a single flat list. The result is a deduplicated inventory of link destinations present in that exact source file, not a live network report or a finished SEO score. The Link Extractor performs this work locally in the browser: paste the HTML, optionally supply the page URL so relative paths resolve into absolute addresses, then copy the deduplicated output. The tool never requests any discovered destination, which keeps the operation safe for pages you are authorized to inspect. JavaScript-injected links, HTTP status codes, redirect chains, canonical intent, and rel attribute meanings are not evaluated at this stage. The deduplication is exact after normalization, the parser decodes numeric and a small set of named character references, and the output is one URL per line with transparent counts. Use the list as a starting inventory that needs separate verification before it is trusted as a navigation signal.
Page source is the raw HTML the server delivered, before scripts run and before the browser rewrites it into a live DOM. That distinction matters when you search for "extract all urls from page source" because the answer depends on which version of the page you actually have. If your source came from a JavaScript-driven single-page application, you will only see the anchor, area, and link tags the server sent. Any link inserted by a framework after render is not in the static source and therefore will not appear in the inventory.
How Source Parsing Differs From Browser Crawling
A link inventory is fundamentally different from a crawl report, even though both answer a similar question about which URLs a page links to. Link Extractor works as a bounded source parser. It removes comments and raw-text containers such as script, style, textarea, title, iframe, noembed, and noframes before scanning start tags, then matches href attributes on a, area, and link elements. It does not execute scripts, render a framework, or open a network connection.
A real browser crawler, by contrast, fetches the document over HTTP or HTTPS, builds a DOM, runs the JavaScript, waits for late requests, then enumerates the resolved links after all that work completes. Both approaches can be valid, but they answer different questions. A source parser tells you what the HTML literally contains; a crawler tells you what a user would actually see and click. For an SEO audit you often want both views, and you should know which one you are looking at before drawing conclusions.
| Source parser inventory | Browser crawler report |
|---|---|
| Reads only the HTML you paste | Fetches the URL over HTTP or HTTPS |
| Scans a, area, and link start tags | Walks the rendered DOM, scripts included |
| Resolves relative hrefs against an optional base | Uses the live page URL as the resolution context |
| Skips executable schemes and empty values | Follows every navigable target |
| Reports unique, duplicate, and skipped counts | Reports status codes, redirects, and timing |
| No network requests to discovered targets | Makes a request to every discovered target |
How to Extract All URLs From Page Source
- Open the page you are authorized to inspect, then use your browser's View Source or Save Page As action to copy the raw HTML. Avoid using the live DOM from the Elements panel, because that view reflects script-driven edits the parser will not see.
- Visit Link Extractor and paste the HTML into the source field. The parser handles up to 200,000 characters per scan, so split very large documents or use your own controlled crawler for full archives.
- If the page contains relative paths such as /pricing or ../guide, enter the page's absolute HTTP or HTTPS URL into the base field. The base must use http or https and cannot contain credentials.
- Run the extraction. The output panel shows a deduplicated, one-URL-per-line list together with unique, duplicate, and skipped counts.
- Copy the result into a spreadsheet, a controlled crawler, or a sitemap builder. Treat each line as an inventory entry that needs separate verification before it is trusted as a navigation signal.
The duplicate count is informative on its own. Two identical relative links that resolve to the same absolute URL collapse into one entry, so the duplicate number tells you how many anchors the parser saw but removed. The skipped count tells you how many empty values, fragment-only references, javascript: and data: targets, and invalid absolute URLs the parser discarded. An apparently short list is rarely a sign of broken extraction; it is usually a sign of conservative filtering, and the parser surfaces the decision rather than hiding it.
Which Targets the Parser Keeps and Skips
The tool intentionally reads three kinds of start tags. Ordinary a anchors point users to documents, area elements add targets inside image maps, and link elements reference stylesheets, icons, canonical pages, and alternate resources. Including all three is the right call for a source inventory, because the goal is to know what the markup contains rather than to guess which relationships matter. The parser does not label any target as navigational, canonical, preload, or stylesheet. You decide that based on the element type and the surrounding context.
Some targets are skipped on purpose. Empty href values, same-document fragments like #section, and executable or embedded-data schemes (javascript, data, vbscript) are never returned. Invalid absolute URLs are dropped as well. Mail (mailto) and telephone (tel) targets are kept because they are legitimate link destinations even though they are not web pages. If a link looks missing from the output, check the skipped count first.
| Target shape | Outcome |
|---|---|
| Absolute http or https URL | Normalized and listed |
| Root-relative such as /pricing | Resolved against the base when supplied |
| Path-relative such as ./guide | Resolved against the base when supplied |
| Parent-relative such as ../guide | Resolved against the base when supplied |
| Scheme-relative such as //cdn.example.com/x | Resolved against the base when supplied |
| mailto: or tel: target | Retained as a legitimate destination |
| Same-document fragment #x | Skipped |
| Empty href value | Skipped |
| javascript:, data:, vbscript: | Skipped for safety |
| Invalid absolute URL | Skipped |
For example, a relative href of /pricing under the base URL https://example.com/products/page resolves to https://example.com/pricing in the output. Without a base, the same href stays as /pricing so the parser never invents a host.
How Character References Are Decoded
Real HTML does not always carry raw ampersands or accented characters inside href values. Link Extractor decodes decimal character references such as & and hexadecimal ones such as &, then applies a small named set covering amp, quot, apos, lt, and gt. Together that covers the URL query escaping most pages use, including the very common & sequence inside tracking parameters.
Anything outside that set stays encoded. The parser is deliberately not a full HTML named-character database, because a guessed or incomplete global entity table can silently rewrite text that looks like markup into something unintended. If a rare named reference survives in the output, treat the encoded form as the real source value rather than as a defect, and verify it downstream if your crawler needs the resolved form.
Use the URL List as an SEO Audit Starting Point
Once the inventory is in hand, the work shifts from extraction to review. The list is intentionally raw: it does not label internal versus external targets, evaluate rel attributes, or test HTTP status. For a migration, a content audit, or a backlink sweep, that bare list is often exactly what you need. You can sort it, filter it, and feed it into another tool that does the next job.
For example, after pruning obvious duplicates and off-domain destinations, the cleaned inventory is a good candidate for a standards-based XML sitemap. That conversion step turns the inventory into something search engines will accept. Link Extractor is the source-discovery phase, the sitemap builder is the publishing phase, and a real crawler is the verification phase. None of those tools replaces the others.
Limits and Pitfalls of Reading Page Source
A source parser is conservative by design, and that creates a few predictable blind spots. First, deduplication is exact after normalization: URLs that differ by tracking parameters, fragments, case-sensitive paths, or redirect behavior are treated as different resources, because the parser cannot tell from the source whether they identify the same destination. Two identical relative links that resolve to the same absolute URL collapse into one entry, but a URL that simply looks similar to another will not.
Second, severely malformed markup, unusual unquoted attributes, missing raw-text closing tags, or browser error recovery can produce a different DOM from the bounded scan. The parser is not a full HTML tree builder, and the interface states that limitation. For any audit where the answer must be defensible, compare the original source, a browser DOM export, and a real crawler rather than relying on a single extraction channel.
Finally, the parser cannot fetch a remote URL. Arbitrary cross-origin requests are often blocked, and silently contacting pasted links would create privacy and security problems. Copy page source from a page you are authorized to inspect, or obtain HTML through your own controlled crawler. Dynamic links inserted after scripts run will not exist in static source and therefore will not be found here.
What to Do Once You Have the Inventory
The list is the beginning of an audit, not the end. Verify each target with an authorized tool that can check HTTP status, redirect chains, authentication requirements, robots rules, and the meaning of rel attributes such as nofollow, sponsored, and ugc. Use the inventory to drive your questions, then let a crawler answer them.
For large or recurring jobs, pair the inventory with a controlled crawler that respects robots.txt and your own authentication boundaries. Treat the Link Extractor as the source-discovery phase, the sitemap builder as the publishing phase, and the crawler as the verification phase. Three small tools, each with a clear job, usually beats one large tool that tries to do everything at once and ends up doing nothing well.