Extract URLs from a sitemap on Windows by pasting the complete XML text into a browser-based parser and copying the verified one-URL-per-line output. The Sitemap URL Extractor performs the parsing locally in your browser without uploading the XML. It does not fetch a sitemap from a remote address, so you must obtain and copy the XML source first.
Prepare the sitemap source on Windows
A Windows sitemap extraction has two separate parts: getting the complete XML into the clipboard and parsing its direct location elements. If you have only a website address, first locate an actual sitemap XML response; the extractor does not crawl a site or discover sitemap files. This guide to finding sitemap URLs in your browser can help with that preliminary step.
| Windows situation | Preparation | What the extractor receives |
|---|---|---|
| Downloaded XML file | Open the file in Notepad or another plain-text editor, select all with Ctrl+A, and copy it with Ctrl+C. | The complete text from one urlset or sitemapindex document. |
| XML available at a web address | Open the response in your browser and copy the full XML source. If it appears as an XML tree, use the browser's view-source option. | The XML after you copy it manually; the extractor makes no network request. |
| Compressed .gz sitemap | Decompress the file outside the extractor and open the resulting XML text. | Decompressed XML, not gzip bytes or a .gz address. |
| Sitemap index | Paste the complete index XML as a separate document. | The direct locations of child sitemap files, not their page URLs. |
Copying only a visible URL, a fragment of the XML, or the address of the sitemap will not provide the input the parser needs. Paste the document itself.
Extract URLs from sitemap on Windows
The following workflow keeps the input and output clear: one complete XML document goes in, and a verified URL list comes out.
- Open the extractor in your Windows browser. Locate its XML editor.
- Paste the complete XML text from one urlset or sitemapindex document. Use Ctrl+V after preparing the source with a text editor or browser source view.
- Run the extraction. The parser reads the direct loc children rather than treating every URL-looking string in the file as a result.
- Review the detected root type, unique URL count, duplicate count, and complete output. Confirm that the result matches the kind of document you pasted.
- Inspect the one-URL-per-line list. The first-seen order is preserved, making it easier to compare the output with the source. Normalized duplicate URLs are omitted after their first occurrence.
- Copy the complete list with the copy control. You can paste it into a spreadsheet, crawler checklist, redirect audit, log comparison, or migration review.
- Perform separate live checks as needed. Verify HTTP status, redirects, canonical tags, robots directives, noindex directives, and indexing separately; none of those checks are part of extraction.
If the run fails, do not treat the result as a partial URL inventory. The parser intentionally fails the whole operation rather than presenting an incomplete list as complete.
Choose the structure before interpreting the list
The detected root type determines what the extracted locations mean. A urlset contains URL entries, and every entry must have a direct loc child. Its output represents the page locations listed in that file. A sitemapindex contains sitemap entries, and every entry must likewise have a direct loc child. Its output represents child sitemap file locations.
A sitemap index is therefore a directory of sitemap files, not a recursive bundle of every page. The extractor does not fetch those child files or expand their contents. After reviewing the index output, obtain each referenced sitemap separately, paste its XML, and run the extraction again for that file.
- A consistent namespace prefix such as sm:urlset, sm:url, and sm:loc is supported, as is the common default namespace form.
- XML declarations and comments are ignored.
- Optional children such as lastmod do not change the extracted location.
- An extension location such as image:loc is not substituted for a missing page loc because it represents a different resource role.
Review counts, normalization, and ordering
The results panel gives you more than a finished list. It explains what was parsed and provides counts you can use to compare the output with the source document.
| Result shown | Meaning | Recommended check |
|---|---|---|
| Detected root type | Whether the pasted document is a urlset or sitemapindex. | Confirm this matches the XML you intended to paste. |
| Unique URL count | The number of validated, deduplicated URLs accepted into the output. | Compare it with the expected locations in the source. |
| Duplicate count | The number of normalized duplicates removed. | Review host-case or default-port variants that collapsed to the same URL. |
| Complete output | The full one-URL-per-line list in first-seen order. | Copy the whole list only after confirming the extraction succeeded. |
Duplicates are identified after URL serialization. The browser-standard process lowercases and validates hosts, removes default ports, and percent-encodes non-ASCII path characters when required. This behavior follows the principles described in the WHATWG URL Standard. If two source locations serialize to the same value, the first occurrence is returned and later copies are removed.
Every accepted location must be an absolute HTTP or HTTPS URL. Credentials, fragments, raw whitespace, malformed percent escapes, backslashes, relative paths, and other URL schemes are rejected. Each serialized URL must also contain fewer than 2,048 characters.
Resolve parser failures at the source
The parser does not repair malformed XML or guess where a missing closing tag belongs. Several conditions cause the entire extraction to fail, including:
- An incomplete root or item, a missing closing tag, or otherwise malformed XML.
- A missing direct loc child or nested markup inside a loc element.
- Unknown XML entities, invalid Unicode scalar values, DTD declarations, or custom entity declarations.
- A decoded loc that is not an absolute HTTP or HTTPS URL or that contains a rejected character sequence.
The five predefined XML entities and valid decimal or hexadecimal numeric character references are accepted. XML text is decoded conservatively. DTDs and custom entities are rejected to keep parsing predictable and prevent entity expansion from becoming hidden behavior. When a problem is found, the error identifies the numbered loc or item so you can correct the source instead of silently skipping it.
There are also two whole-operation input limits: at most 50,000 unique URLs and five million UTF-16 input code units. Crossing either bound fails the extraction without truncating the output. If a production sitemap is near protocol limits, validate its actual uncompressed byte size separately and consider splitting it into smaller files referenced by a sitemap index.
Turn the list into an SEO audit checklist
The extracted URLs are best treated as the starting point for a broader review. The list is useful for a crawler checklist, spreadsheet import, redirect audit, log comparison, or migration review. Once copied, check the live URLs for:
- HTTP status and redirect behavior.
- The canonical tag and the canonical URL actually selected by search engines.
- Robots directives and noindex directives.
- Crawl and index data, content quality, ownership, and current availability.
Compare the list with canonical URLs from your database, crawl results, analytics landing pages, or a previous release. Unexpected duplicates can expose default-port or host-case variants. Google's guide to building and submitting a sitemap also makes an important distinction: sitemaps help discovery, but they do not guarantee crawling or indexing.
Know what the Windows extraction does not prove
A successful extraction confirms only that a location appeared in the pasted structure and passed the tool's disclosed URL validation. It does not check HTTP status, redirects, canonical tags, robots directives, noindex directives, page content, ownership, sitemap placement, UTF-8 bytes on disk, or whether a search engine accepted the source file.
Inspect the live sitemap response and relevant pages separately. The result is evidence within a larger audit, not proof that a URL is crawlable, canonical, valuable, indexed, or ranked. Because parsing happens in the browser and the XML is not uploaded, private staging locations or prelaunch URL inventories remain on the Windows device unless you copy them somewhere else.
For a deeper look, see Free UTM Builder, No Sign-Up: Build Campaign URLs.