Extract sitemap from URL into a clean, deduplicated, one-URL-per-line list by pasting the XML text into a browser-side parser that never uploads the source file. The Sitemap URL Extractor does exactly this: it accepts a complete urlset or sitemapindex document, extracts every direct loc value, and reports the root type, the number of unique URLs accepted, and the count of normalized duplicates it removed. Because every byte stays in your browser tab, the source XML is never sent to a third-party server, which keeps staging sitemaps, prelaunch URL inventories, and other sensitive lists on your own device. The parser follows the Sitemaps protocol structure and applies the browser's WHATWG URL serialization, so what you copy is a deterministic list you can paste into a spreadsheet, a redirect mapper, or a downstream audit tool. The rest of this article walks through the exact paste-and-parse workflow, what each output number means, where the validation rules will reject a loc, and how to use the resulting list without confusing extraction with indexing.
What "Extract Sitemap From URL" Means in This Workflow
The phrase "extract sitemap from URL" usually means two related things: you have a sitemap address such as https://example.com/sitemap.xml and you want the page URLs inside it. The Sitemap URL Extractor does not fetch that address itself. The widget makes no network request, so you cannot paste a remote address and wait for a result. Instead, the workflow assumes you have already obtained the raw XML text by opening the URL in your browser, viewing source, downloading the file, or asking your CDN or hosting panel for the file contents, and then pasting that exact text into the editor. This keeps the source data local, avoids leaking sitemap structure to an external service, and lets you work offline once the text is on your clipboard. If your sitemap is gzip-compressed, which is common on larger sites, decompress it first with your operating system or a local tool before pasting, because the parser reads plain XML text only. Treating the workflow as a paste-and-parse step, rather than a fetch-and-parse step, also keeps staging sitemaps and prelaunch URL inventories on the device unless you copy them elsewhere.
Paste the XML and Get a URL List
- Open the source sitemap in your browser or download it, then copy the complete XML text from a single urlset or sitemapindex document, including the XML declaration and namespace prefix if present.
- Paste the copied XML into the Sitemap URL Extractor editor. The widget begins parsing as soon as valid XML text is present.
- Review the reported root type (urlset or sitemapindex), the unique URL count that was accepted, the duplicate count that was removed, and the complete one-URL-per-line output.
- Confirm that the numbers match your expectations. If the duplicate count is higher than zero, check whether default-port or host-case variants have been collapsed by the browser's URL serializer.
- Use the copy button to place the complete verified list on your clipboard, then paste it into a spreadsheet, redirect mapper, crawler checklist, or migration review.
- Run separate live checks for HTTP status, canonical tags, robots directives, and indexing, because extraction only confirms that the location appeared in the pasted structure.
Reading the Root Type, Unique Count, and Duplicate Count
Three numbers and one label appear at the top of the result: the root type, the unique URL count, the duplicate count, and the deduplicated list itself. The root type tells you whether the parser saw a urlset with page entries or a sitemapindex with child sitemap entries, the two structures the Sitemaps protocol defines and the only two the parser recognizes. The unique count is the number of absolute HTTP/HTTPS loc values that survived every validation rule, in first-seen order. The duplicate count is the number of entries that serialized to a value already seen earlier in the document; those are removed silently so the output stays clean. Unexpected duplicates often point at small source inconsistencies such as a trailing slash on some entries and not others, a default port being spelled out, or mixed host casing that the browser normalizes. If the unique count looks low or the duplicate count looks high, inspect the source XML for these patterns before drawing conclusions about the site itself.
Sitemap Index vs URL Set Results
A sitemap index is a directory, not a bundle of every page URL. When the parser detects a sitemapindex root, the resulting list contains only the direct loc values of the child sitemap files, for example https://example.com/sitemap-posts.xml and https://example.com/sitemap-pages.xml. The tool does not fetch those files, does not follow them, and does not expand them into page URLs. To get a flat list of every page URL across a multi-file sitemap, you must obtain each child file separately through curl, a browser save, or your hosting dashboard, paste each one through the extractor, and concatenate the results yourself. The output from a urlset root, by contrast, is the page URLs themselves and can be used directly for downstream checks. The same rules apply whether you use a namespace prefix such as sm:urlset or the default-namespace form, as long as the prefix is used consistently throughout the document.
| Aspect | urlset input | sitemapindex input |
|---|---|---|
| Root element | urlset | sitemapindex |
| Each item contains | url with a loc child | sitemap with a loc child |
| Output list contains | Page URLs | Child sitemap file URLs |
| Recursive expansion | Not applicable | No, each child obtained separately |
| Optional children ignored | lastmod, changefreq, priority | lastmod |
| Common namespace prefix | sm:urlset, sm:url, sm:loc | sm:sitemapindex, sm:sitemap, sm:loc |
Validation Rules the Parser Enforces
The Sitemap URL Extractor is intentionally strict. Every decoded loc must be an absolute HTTP or HTTPS URL; the parser rejects relative paths, credentials, fragments, raw whitespace, malformed percent escapes, backslashes, and non-web schemes. Each URL is normalized with the browser's WHATWG URL implementation, which lowercases hosts, removes default ports, and percent-encodes non-ASCII path characters where required. After normalization, each URL must be shorter than 2,048 characters, matching the Sitemaps protocol's loc constraint. XML text is decoded conservatively: only the five predefined XML entities and valid decimal or hexadecimal numeric character references are accepted, and any unknown entity, invalid Unicode scalar value, nested markup inside a loc, DTD declaration, or custom entity declaration causes the entire run to fail rather than producing a partial list. XML declarations and comments are ignored, optional children such as lastmod do not affect the extracted location, and extension locations such as image:loc are never substituted for a missing page loc because they describe a different resource role.
Hard Limits and Why the Whole Run Fails
Two hard bounds apply. The parser accepts at most 50,000 unique URLs and at most five million UTF-16 input code units. Crossing either bound fails the entire run without truncation, so a partial list is never returned as if it were complete. If a production sitemap sits near those limits, validate the actual uncompressed byte size and consider splitting it into smaller files referenced by a sitemap index, which is the standard pattern the Sitemaps protocol recommends for large sites. Because the parser does not repair malformed XML or guess where a missing closing tag belongs, a numbered locator on any parser error points at the exact loc or item that caused the failure so the source can be corrected and re-pasted. Treat the resulting list as evidence in a larger audit rather than as proof that the URLs are crawlable, canonical, or indexed; extraction only confirms that the loc appeared in the pasted XML and passed the disclosed validation.
Where the Extracted List Goes Next
A clean URL list is the starting point for several adjacent tasks. Compare it against the canonical URLs in your database to spot duplicate-content candidates; compare it against a previous release to spot removed pages; import it into a spreadsheet and sort by path prefix to look for orphans; or paste it into the XML Sitemap Generator if you need to rebuild a sitemap from a reviewed list. For live status, canonical, robots, and indexing checks, use dedicated tools that fetch each URL, because extraction cannot tell you whether a page returns 200, whether the canonical tag points to itself, or whether a search engine has indexed it. Google's sitemap documentation describes sitemaps as discovery hints rather than indexing guarantees, which is why the extracted list is best treated as the input to a broader audit instead of its conclusion. The WHATWG URL standard governs how the parser normalizes each loc, so identical-looking URLs that differ only in host case or default port will be deduplicated correctly.