A sitemap URL extractor parses pasted XML and returns the direct loc values as a deduplicated one-URL-per-line list inside your browser, without uploading the file. The Sitemaps protocol defines two structures: a urlset containing page entries and a sitemapindex listing child sitemap files. The extractor reads only the loc child of each url or sitemap element, ignoring optional fields like lastmod and ignoring extension elements like image:loc. The result preserves first-seen order and reports which root type was detected, how many unique URLs survived normalization, and how many duplicates were removed. Because every decoded loc must serialize as an absolute HTTP or HTTPS URL under 2,048 characters, malformed entries fail the entire run instead of being silently skipped. This produces a clean evidence list for audits, migrations, crawler checklists, and spreadsheet work, but it does not prove anything about live indexing status, canonicalization, or HTTP response codes — those checks happen against the live site, not the XML.
What the Extractor Reads From Pasted XML
The tool operates on XML text you paste into a browser editor. It does not download, decompress, or follow remote sitemaps, and pasting a URL into the editor does not retrieve anything either. To feed it, open your saved sitemap file, copy the raw XML, and paste it in; if the file is gzipped, decompress it outside the tool first because compressed .gz data is not accepted as input.
Once pasted, the parser strips the optional byte-order mark, XML declarations, and comments before walking the structure. It supports both the default-namespace form (xmlns="http://www.sitemaps.org/schemas/sitemap/0.9") and a consistent namespace prefix such as sm:urlset, sm:url, and sm:loc. DTD declarations and custom entity declarations cause the run to fail on purpose — the parser does not want to silently expand entities it has not reviewed, because hidden expansion can change the meaning of the output. Rejecting DTDs keeps the widget's behavior small and predictable, and it means a malformed source surfaces as an explicit error instead of a partial list that looks finished.
urlset vs. sitemapindex: Different Inputs, Different Outputs
Many people paste a sitemap expecting one thing and get another. The two core structures defined by the protocol produce different lists, and knowing which one you have matters before you start an audit or migration.
| Structure | What each loc means | What you receive from the extractor |
|---|---|---|
| urlset | A page that should be discoverable | Direct page URLs from every url/loc |
| sitemapindex | A child sitemap file to fetch next | Direct sitemap file URLs from every sitemap/loc |
A sitemap index is a directory of sitemap files, not a recursive bundle. The extractor returns the file locations inside the index and stops there; it does not fetch those files or expand their page URLs. To get the page URLs from an index, obtain each child file separately and run it through the tool again. If you need help assembling the rules for the inverse workflow, the sitemap protocol rules for building from a URL list cover the same constraints from the generation side.
Inputs the Parser Will Reject
The parser is strict on purpose. XML text is decoded conservatively: only the five predefined named XML entities and valid decimal or hexadecimal numeric character references are accepted, and unknown entities cause the run to fail. Nested markup inside loc, missing loc children, incomplete url or sitemap items, and malformed roots all fail the entire operation rather than producing a partial list.
After decoding, every value is parsed with the browser's WHATWG URL implementation. Only absolute HTTP and HTTPS URLs shorter than 2,048 characters pass. That means credentials, fragments, raw whitespace, malformed percent escapes, backslashes, relative paths, and any other scheme are rejected. Extension locations such as image:loc are never substituted for a missing page loc, because they describe a different resource role. If the run fails, the error is intentionally specific to the numbered loc or item so the source can be corrected rather than silently skipped.
Extract URLs From a Sitemap in Three Steps
- Paste the complete XML text from one urlset or sitemapindex document into the editor. Do not paste a URL — the widget does not download anything.
- Extract the direct loc values and review the summary: the detected root type, the unique count, the duplicate count, and the complete output. The list is in first-seen order so you can compare it with the source XML line by line.
- Copy the one-URL-per-line list to your clipboard, then run separate live status, canonical, robots, and indexing checks against the URLs as needed. The list is evidence; it is not a substitute for crawling the live site.
For a complete walkthrough of the same workflow with examples, see the Sitemap URL Extractor tool page. If your sitemap is close to the protocol's uncompressed size cap and the run fails on the size limit, split the source into smaller files referenced by a sitemap index and process each one individually.
Hard Limits: Size, Character Count, and Duplicates
Two hard limits govern the run. The browser tool accepts at most 50,000 unique URLs and 5 million UTF-16 input code units. Crossing either bound fails without truncation, so a half-parsed list is never presented as a finished result. Each serialized URL must also contain fewer than 2,048 characters, matching the protocol's loc constraint; longer entries are dropped along with the rest of the run.
Normalization is the other constraint to plan for. Browser-standard serialization lowercases and validates hosts, removes default ports, and percent-encodes non-ASCII path characters when required. URLs that serialize to the same value are duplicates, and only the first occurrence is returned. The duplicate counter in the summary tells you how many entries were collapsed this way. Unexpected duplicates often reveal default-port or host-case variants — for example, https://example.com/ and https://Example.com:443/ serialize to the same value and only one survives. If duplicates are large in number, that is a useful signal that your source has format drift worth fixing before resubmitting the sitemap.
What an Extracted URL Does and Does Not Prove
Extracting a URL confirms only that the location appeared in the pasted structure and passed this tool's disclosed validation. It does not mean the URL is crawlable, canonical, valuable, indexed, or ranked. The Sitemaps protocol and Google's documentation describe sitemaps as discovery hints, not indexing guarantees, so any claim that goes beyond "this loc was in valid XML" needs a separate live check.
Use the list as evidence in a larger audit rather than as proof of indexation. Compare it with canonical URLs from your database, crawl results, analytics landing pages, or a previous release. For more on the broader audit pattern, the extract links from a sitemap for audits and migrations guide walks through the comparison side of the workflow.
Because the widget is client-only, private staging locations or prelaunch URL inventories stay on the device unless you copy them elsewhere. After using the list, inspect the live sitemap response and the relevant pages separately — status codes, redirects, robots directives, noindex tags, and canonical selection all live outside the XML and must be tested against the live site, per Google's sitemap documentation and the WHATWG URL Standard.