An XML sitemap for a website is a UTF-8 file that lists the pages you want indexed, wrapped in a urlset element that uses the official http://www.sitemaps.org/schemas/sitemap/0.9 namespace from the sitemaps.org protocol. The XML Sitemap Generator turns a reviewed list of page URLs into exactly that file: one absolute HTTP or HTTPS URL per line, deduplicated in first-seen order, optionally tagged with a shared lastmod, changefreq, or priority, and serialized through the browser URL parser so hosts are lowercased, default ports are removed, and non-ASCII path components are percent-encoded. Each generated file is restricted to one serialized host, including any non-default port, so HTTP and HTTPS URLs for the same host can coexist while example.com and example.com:8443 cannot. All parsing, normalization, XML escaping, and download blob creation happen in the current tab, which means pasted URLs and the finished XML are never uploaded to a remote server. The output is only as accurate as the URLs you paste, so redirects, canonical targets, and private pages must be reviewed before the file is published.
How the generator turns a list into XML
The generator is a list-to-XML utility, not a crawler. It accepts a block of text you have already curated, validates every nonblank line, normalizes the URLs, removes duplicates while preserving first-seen order, escapes the five XML entities, and emits a complete UTF-8 XML file ready for download. It does not visit any page, follow any link, inspect canonical tags, read modification dates, discover redirects, verify HTTP status, determine indexability, or submit the result to a search engine. There is no sitemap index generation, no image, video, or news extension, no hreflang markup, no gzip file, no robots.txt rules, and no Search Console submission. If you paste a malformed URL or a banned fragment, the whole generation fails rather than silently skipping the line, and if you exceed the tool's safety budget, the generation fails rather than truncating. The list-only nature of the tool is also why it is safe to use on sites you cannot crawl, such as manually exported competitor domains or staging environments behind authentication, because nothing leaves your tab.
Accepted input format and the single-host rule
Each nonblank line must be an absolute HTTP or HTTPS URL with no leading or trailing whitespace. The generator accepts LF, CRLF, and CR line endings and ignores whitespace-only lines. Bare domains, relative paths, FTP URLs, raw control characters, malformed percent escapes, embedded credentials, and URL fragments are all rejected. Because fragments are not sent to the server as part of the HTTP request, allowing them would risk creating multiple sitemap entries for the same fetched resource, which is why they are filtered out. Credentials are rejected so a username or password cannot be copied into a public sitemap, even by accident.
The single-host rule comes straight from the sitemaps.org protocol: one file lists URLs from one host. The browser tool enforces this by serializing every accepted URL through the WHATWG URL parser and then comparing hosts in their normalized form. An uppercase host and its lowercase form identify the same URL, and an explicit default port is treated as identical to its stripped form. HTTP and HTTPS for the same host are accepted together because the scheme is not part of the host comparison, but example.com and example.com:8443 cannot appear in one file because the non-default port becomes part of the serialized host. If you need to publish sitemaps for two different hosts or two different non-default ports, generate two separate files instead of trying to mix them.
Optional metadata fields applied uniformly
The three optional fields are lastmod, changefreq, and priority. If you leave them blank, the generator emits loc-only XML. If you fill them in, the same value is applied to every URL in the file, which is why the tool insists on a truthful shared value rather than guessing a per-URL default. Last modified accepts a real Gregorian YYYY-MM-DD date or a complete date-time with seconds and either a Z or a valid UTC offset, and calendar dates, leap years, clock field ranges, and timezone limits are all checked. Leading or trailing whitespace on the field is rejected rather than trimmed. Change frequency accepts exactly seven strings defined by the protocol: always, hourly, daily, weekly, monthly, yearly, or never. Priority accepts a decimal from 0.0 through 1.0.
These three fields are protocol hints, not crawl commands or ranking guarantees; they tell crawlers what you assert about the page, not what the page is worth. Invalid optional metadata fails the whole generation, so a bad date or an out-of-range priority is just as fatal as a malformed URL. For a deeper look at how each option interacts with the protocol, the practical guide to building an XML sitemap walks through the same metadata choices in a workflow context.
How to generate a validated sitemap.xml
- Assemble a reviewed list of absolute page URLs that all belong to one host, including any non-default port, and decide whether to publish separate files per host or per scheme group.
- Open the XML Sitemap Generator and paste one URL per line into the editor. Trim leading or trailing whitespace manually, because the tool will not silently remove it.
- Decide whether to leave the optional fields blank for loc-only XML or to apply a truthful shared lastmod, changefreq, or priority that genuinely applies to every entry.
- Click generate and review the finished XML, the unique URL count, the duplicate count, and any error lines. The preview reflects the exact bytes that will be downloaded.
- Download sitemap.xml, publish it on the same host it represents, and submit the URL through the channel your search engine supports. Google's build and submit a sitemap documentation walks through that last step.
Limits the browser tool enforces below the protocol
The sitemaps.org protocol permits fewer than 2,048 characters in each loc, up to 50,000 URLs per file, and up to 52,428,800 uncompressed bytes. The browser tool intentionally uses lower whole-file budgets because every limit is bounded by the memory available to a single tab for preview, Blob, and parsing:
| Limit | Protocol maximum | Browser tool ceiling |
|---|---|---|
| Unique URLs per file | 50,000 | 10,000 |
| Uncompressed file size | 52,428,800 bytes | 10,485,760 bytes (10 MiB) |
| Characters per loc | fewer than 2,048 | at most 2,047 after normalization |
| Input size | not specified | 5,000,000 UTF-16 code units |
Every limit is all-or-nothing: the 10,000th unique URL is accepted and the next unique URL fails, the exact 10,485,760-byte boundary is accepted and one additional byte is rejected, and duplicate lines do not consume output slots. No shortened XML, ellipsis, capped preview, or partial download is returned. XML size is measured after URL serialization, XML escaping, optional tags, indentation, and UTF-8 encoding, which is why a file that looks small in the editor can approach the limit once escaped. If your site is larger than 10,000 unique URLs, split the list into multiple host-aligned files and use a sitemap index, which the tool does not generate for you.
What to verify before publishing sitemap.xml
The generator cannot tell you which pages belong in the file. Review redirects, duplicate content, blocked pages, private pages, staging URLs, and missing pages before you publish. Confirm that every loc actually returns a 200 status, that canonical tags point where you expect, and that any noindex directive is intentional rather than a leftover template. The optional lastmod, changefreq, and priority values you provide become public assertions about your pages, so resist the urge to set every URL to priority 1.0 or every page to daily; truthful shared values build trust with crawlers over time. Once the file is live, monitor coverage and crawl reports rather than treating the sitemap as a one-time deliverable, because a sitemap is a hint, not a guarantee of indexing.
Related reading: Extract Sitemap From URL: A Paste-and-Parse Workflow.