To extract all URLs from a sitemap means turning one XML document into a clean, one-URL-per-line list with the surrounding markup stripped away. The result is plain text that a human can scan, a spreadsheet can import, or a crawler checklist can compare against a previous release. A sitemap XML file or sitemap index is, at its core, a small wrapper around repeated loc elements; once those loc values are pulled out, every other field becomes noise for the purpose of URL extraction. The Sitemap URL Extractor handles this transformation locally in your browser by recognizing the two structures defined by the Sitemaps protocol, decoding the limited set of entities that protocol-compliant files use, normalizing each URL with the browser's URL parser, deduplicating collisions in first-seen order, and placing the final list on the clipboard. Nothing is uploaded, so private staging sitemaps stay on the device, and the accepted size and structure rules below describe how that local pipeline behaves in practice.
What the Extraction Actually Returns
Every standard sitemap falls into one of two root types: urlset, which lists page-level locations, or sitemapindex, which lists other sitemap files. The extractor reads the root element, then walks straight into each loc child. For a urlset, that means each url entry's direct loc child becomes one line of output. For a sitemapindex, the same rule applies to each sitemap entry's direct loc child, so the output is the list of sitemap file URLs rather than the pages inside them.
Decoded values go through the browser's WHATWG URL parser before they are accepted. The parser lowercases the host, removes default ports, percent-encodes non-ASCII path characters when needed, and rejects anything that is not an absolute HTTP or HTTPS URL. Anything carrying credentials, a fragment, raw whitespace, malformed percent escapes, a backslash, or a non-web scheme is dropped rather than repaired. The tool reports which root type was found, how many unique URLs were accepted, and how many duplicates were removed during normalization, so a quick glance at the panel tells you whether the source was a clean urlset, an index of child files, or something the parser could not accept.
| Root element | Source XML | What you get back |
|---|---|---|
| urlset | A list of url entries, each with a direct loc child | One line per page-level location, deduplicated |
| sitemapindex | A list of sitemap entries, each with a direct loc child | One line per child sitemap file URL; the pages inside those files are not expanded |
First-seen order is preserved, so the output remains easy to compare with the source: line N of the result corresponds to the Nth valid loc the parser encountered. If the deduplication count is unexpectedly high, common causes are default-port variants (such as example.com:80 versus example.com), mixed host casing (such as Example.com versus example.com), and trailing-slash or percent-encoding differences that the WHATWG parser normalizes away. Tracking the duplicate count run over run is also a quick way to spot a sitemap that has been rebuilt from inconsistent sources.
Inputs the Tool Accepts and What It Rejects
The extractor is deliberately small, so its input contract is precise. It accepts the complete XML text from exactly one urlset or one sitemapindex document. A consistent namespace prefix such as sm:urlset, sm:url, and sm:loc is supported alongside the default namespace form. XML declarations and comments are stripped before parsing. The five predefined XML entities — <, >, &, ', and " — plus valid decimal or hexadecimal numeric character references are decoded; anything else, including custom entity declarations and DTDs, is rejected.
The protocol-style limits are enforced as hard caps. Each serialized URL must contain fewer than 2,048 characters, matching the protocol's loc constraint. The widget accepts at most 50,000 unique URLs and five million UTF-16 input code units; crossing either bound fails the run rather than truncating the output. Compressed .gz data must be decompressed outside the tool, and pasting a remote URL into the editor does not download anything — only XML text is processed.
How to Extract All URLs From a Sitemap
- Open the raw XML of a single sitemap file or sitemap index in your text editor, then copy the entire contents — from the opening <urlset> or <sitemapindex> through the closing tag — into the extractor editor. If the file is compressed, decompress the .gz first.
- Run the extraction and review the panel that reports the root type, the number of unique URLs accepted, the number of duplicates removed during normalization, and the full output below.
- Use the copy button to place the complete one-URL-per-line list on the clipboard, then import it into a spreadsheet, paste it into a crawler checklist, or save it for comparison with a previous release.
- Run separate live checks for HTTP status, canonical selection, robots directives, and indexing, because extraction only confirms the location appeared in the source XML.
Live Checks the Extracted List Still Requires
An extracted list is evidence of presence, not proof of indexing. The Sitemaps protocol and Google's documentation both describe sitemaps as discovery hints, so a clean extraction is the starting point for a larger audit, not the end of one. Once the list is in hand, the remaining questions belong to a separate, live-site pass.
For each URL on the list, confirm that the live response returns a 2xx status, follows any redirect chain to a stable destination, and that the destination's rel=canonical matches the URL you expected. Cross-check the extracted URLs against robots.txt rules, the page's own meta robots, and any noindex directives. Compare the list against canonical URLs from your database, a previous crawl, or analytics landing pages to surface duplicates caused by default-port or host-case variants. If a production sitemap sits close to the protocol's uncompressed byte-size limits, validate the actual file size and consider splitting it into smaller files referenced by a sitemap index.
Those checks need not be run at the same time. A small site can be spot-checked manually; a large inventory is easier to compare with a headless browser, a log file, or a CSV from your analytics platform, where each row already carries a status code or a canonical destination. The point is that extraction hands you a candidate list and nothing more — every URL on that list still needs to clear the same set of gates before it counts as live, reachable, and indexable.
Extracting vs Building a Sitemap: Two Directions, One Format
Extraction is the reverse of building. The same urlset shape that this tool reads can be produced from a reviewed list of page URLs by the XML Sitemap Generator, and a sitemapindex can be assembled from a collection of smaller sitemap files. Understanding both directions helps when migrating a site, splitting an oversized sitemap, or rebuilding a stale file from a known-good URL list.
| Aspect | Extracting URLs from a sitemap | Building a sitemap from a URL list |
|---|---|---|
| Direction | XML loc values → plain list | Reviewed URL list → protocol-compliant XML |
| Output shape | One URL per line, deduplicated | A urlset or sitemapindex XML file |
| Typical use | Audits, migrations, crawler checklists | Publishing a sitemap for crawlers to fetch |
| What proves it worked | Unique count matches expectations; duplicates explained | File validates against the protocol and serves a 200 |
The two flows share the same hard limits. Each url entry's loc must be under 2,048 characters and must point to a publicly reachable HTTP or HTTPS resource, not a relative path or a non-web scheme. Sitemap indexes have the same cap on each child sitemap file URL but inherit an additional rule: a single sitemap file is expected to contain fewer than 50,000 URLs and stay under 50 MB uncompressed, which is why production sites often split large inventories across multiple child files. The XML Sitemap Generator enforces the same shape when it produces output, so a list extracted today can be re-emitted as a valid file tomorrow without manual rewriting.
Errors That Cause a Run to Fail
The parser is intentionally specific about what it accepts, so failures point to a numbered loc or item rather than silently skipping bad input. DTD declarations and custom entity declarations fail the run because rejecting them keeps the widget's behavior small and predictable and prevents entity expansion from becoming hidden product logic. Unknown entities, invalid Unicode scalar values, nested markup inside a loc, missing loc children, and incomplete items all fail the run for the same reason: a partial list presented as complete would be worse than no list at all.
The parser does not repair malformed XML or guess where a missing closing tag belongs. Extension locations such as image:loc are not substituted for a missing page loc because they describe a different resource role. If a sitemap index looks unexpectedly short, the cause is almost always that the extractor returned the direct child sitemap file locations — those files must be obtained and processed separately to surface their page URLs.
For deeper coverage of the underlying rules, the Google Search Central guide to building and submitting a sitemap and the WHATWG URL Standard are the two authoritative references behind the validation behavior described above.