The Sitemap URL Extractor pastes an entire XML sitemap or sitemap index into a browser editor, pulls the direct loc values from each url or sitemap entry, and returns a deduplicated one-URL-per-line list you can copy straight to the clipboard — no upload, no API key, and no command line. A run is deterministic: the same XML text always produces the same output, and the parser either accepts the document in full or fails the entire run. The widget is built around the two structures the Sitemaps protocol defines, so cheat-sheet users do not need to remember a third-party API surface or library quirks — the rules below are the only ones that matter.
Use this cheat sheet when you have a sitemap open in another tab or in a text file and want a flat URL inventory to feed into a spreadsheet, a redirect audit, a migration review, a crawler checklist, or a log comparison. If you only need to confirm a few locations, scanning the raw XML is fine. If you need a clean, comparable list, the Sitemap URL Extractor is the fastest path that keeps the work local.
What This Cheat Sheet Is For
The sheet captures five things in order: the two root types the tool accepts, the exact steps to run an extraction, the input rules that determine whether the parser will succeed, the limits that will fail an entire run without truncation, and the live-site checks the output does not replace. Skim to the rules table if you have already pasted XML and want to know why a run failed. Jump to the output table if you have a list in hand and want to know what each field means. Read the "what extraction does not prove" section before you treat the list as evidence in an audit.
Because every byte of the pasted XML stays on the device, the same sheet is safe to use on private staging sitemaps, prelaunch URL inventories, and internal discovery files. Confidentiality is part of the contract: nothing is sent over the network while the extractor runs, and copying the result is a manual action you control.
How to Extract URLs From a Sitemap
Open the Sitemap URL Extractor in your browser and follow the four steps below. Each step corresponds to a single deliberate action; do not skip the duplicate review, because the counts you see in step three are the only signal the tool gives you that normalization did what you expected.
- Open the XML source of one urlset or sitemapindex document in another tab or text editor. Make sure you are copying the raw XML, not a rendered HTML preview of it, and do not paste a remote URL — the widget does not fetch anything.
- Paste the complete XML text into the editor. If the source is a compressed .gz file, decompress it first in your file manager so the editor sees plain XML.
- Run the extraction. Review the four values the tool reports: the root type it found (urlset or sitemapindex), the number of unique URLs it accepted, the number of normalized duplicates it removed, and the complete output list.
- Copy the one-URL-per-line list to your clipboard. Use it as a crawler checklist, a spreadsheet import, a redirect audit input, a log comparison target, or a migration review baseline. Run separate live status, canonical, robots, and indexing checks for anything the list should not be trusted to prove on its own.
If you need a longer walkthrough with copy-paste XML examples, the guide on extracting URLs from a sitemap without an API covers the same workflow in a more narrative form.
Input Rules the Parser Enforces
The parser is intentionally narrow. It strips a leading byte-order mark, XML declarations, and comments, then looks for a single root element of one of two types. Anything outside that small grammar causes the run to fail rather than be silently repaired. The table below summarizes the disclosed rules; if your input does not match one of these rows, the extractor will reject the document and tell you which numbered loc or item is at fault.
| Rule area | Accepted | Rejected |
|---|---|---|
| Root element | urlset or sitemapindex | Any other element name, missing root, multiple roots |
| Item element | url inside urlset, sitemap inside sitemapindex | Empty items, items missing a direct loc child |
| Namespace prefix | Default namespace or one consistent prefix such as sm:urlset, sm:url, sm:loc | Mixed prefix and default forms in the same document |
| Entities and references | The five predefined XML entities; valid decimal and hex numeric character references | Custom entity declarations, DTD declarations, unknown named entities, nested markup inside loc |
| Other children of url or sitemap | Optional values such as lastmod are ignored | image:loc, news:loc, or other extension locations used in place of a missing page loc |
| Structure repair | None — the parser does not guess where a closing tag belongs | Malformed XML, incomplete items, incomplete roots |
The "no repair" rule matters for cheat-sheet users. If your production XML was generated by a templating system that emits inconsistent prefixes, fix the generator rather than the sitemap. If a third-party plugin emits a DTD for entity definitions, strip the DTD before pasting — the widget will reject it because allowing DTDs would make entity expansion a hidden part of the product.
Output: What the Tool Returns
After a successful run, the extractor shows the root type, the unique count, the duplicate count, and the complete one-URL-per-line list. The list preserves first-seen order, so you can diff it against a previous export without re-sorting, and the copy button places the entire accepted list on the clipboard. The table below shows what each piece of output is good for and what it does not claim.
| Output field | What it tells you | What it does not tell you |
|---|---|---|
| Root type | Whether you pasted a urlset of page URLs or a sitemapindex of sitemap file URLs | Whether the source is the live file a search engine actually crawls |
| Unique count | How many distinct serialized URLs were accepted from the input | How many pages the site has overall, or how many of those pages are indexed |
| Duplicate count | How many entries collapsed to a URL that already appeared earlier in the document | Whether the duplicates reflect real content duplication or just a host-case or default-port variant |
| Complete output | The deduplicated, browser-normalized list in first-seen order, ready to copy | Whether each URL is crawlable, canonical, indexed, or ranked |
Normalization is conservative and is driven by the WHATWG URL Standard: hosts are lowercased, default ports are removed, and non-ASCII path characters are percent-encoded when required. Credentials, fragments, raw whitespace, malformed percent escapes, backslashes, relative paths, and any scheme other than http or https are rejected. If your list contains unexpected duplicates, that is often a sign of a host-case variant (Example.com vs example.com) or a default-port variant (https://example.com:443/ vs https://example.com/) — both collapse to the same serialized value and only the first is kept.
Limits That Cause a Full Run to Fail
Two hard caps exist, and crossing either one fails the entire run without partial output. The protocol-level loc limit is 2,048 characters per URL, which matches the Sitemaps specification. The widget-level cap is 50,000 unique URLs and 5,000,000 UTF-16 input code units. A single worked check: a serialized loc of exactly 2,047 characters passes the per-URL length rule, while a serialized loc of exactly 2,049 characters is rejected and the run fails on that item. If a production sitemap is close to those bounds, validate the uncompressed byte size and consider splitting it into smaller files referenced by a sitemap index.
A sitemap index is a directory of sitemap files, not a recursive bundle. The extractor returns the direct loc values inside the index, not the page URLs of every referenced child file. If you need the full page inventory across an index, obtain each child file and run it through the extractor separately. Compressed .gz data must be decompressed outside the tool; pasting remote URLs is not supported because the widget makes no network request.
What Extraction Does Not Prove
A URL in the output is a confirmation that the location appeared in the pasted XML and passed the disclosed validation. It is not a confirmation of crawlability, canonical selection, robots permission, indexation, ranking, page quality, or sitemap acceptance by a search engine. The Sitemaps protocol itself treats sitemaps as discovery hints, and the same document can list a URL that returns a 404, redirects away, is blocked by robots.txt, carries a noindex meta tag, or has been removed from the live site hours after the file was generated.
Treat the list as evidence inside a larger audit rather than as a verdict. Compare it against canonical URLs from your database, a fresh crawl, your analytics landing pages, and a previous release of the sitemap. Differences are the audit signal, not the extracted list itself.
After You Copy the List
With a clean URL inventory in hand, the next steps depend on the question you started with. For a redirect audit, join the list against your redirect map and flag entries that point to a destination with a different canonical. For a migration review, diff the list against the previous release and investigate any URL that appears in one but not the other. For a crawler checklist, paste the list into your crawler as a starting set and let it discover links from there. For a log comparison, normalize the log URLs through the same browser-standard rules before matching.
Because the widget is client-only, the list stays on the device until you copy it somewhere. Private staging locations, prelaunch URL inventories, and unreleased sections remain confidential unless you move them out yourself — the parser does not call home, log the input, or store the result.
If you're weighing options, Sitemap Generator Command Line vs Online: How to Decide covers this in detail.