A sitemap generator is a tool that creates a sitemap.xml file — a standards-based list of page URLs on one website host that search engines can read to discover pages. Unlike crawler-type generators that visit your site and follow links to assemble the URL list on their own, a list-to-XML generator like the XML Sitemap Generator takes a reviewed URL list you already maintain and turns it into a UTF-8 XML file in your current browser tab, with no crawling and no upload. The generated file follows the format defined at sitemaps.org, where each entry carries at minimum a location element and may optionally include shared lastmod, changefreq, and priority values. Because the tool only formats the URLs you supply, the output is only as accurate as the review you've already done — duplicate pages, blocked routes, private pages, redirects, and forgotten corners of the site will only appear if you include them.
How a Sitemap Generator Connects to the Sitemap Protocol
The sitemap protocol at sitemaps.org describes a small XML structure with one root element and one repeating child per URL. The root is <urlset> using the namespace http://www.sitemaps.org/schemas/sitemap/0.9, and each child is <url> containing at minimum <loc> — the absolute page URL. Anything beyond that — last modified date, change frequency, priority — is optional and is shared across the file when applied.
A sitemap generator's job is to produce a file that obeys these rules. Three protocol rules in particular shape how a generator has to behave. First, every <loc> must be an absolute URL on a single host; bare domains, relative paths, and fragments are not allowed. Second, the file is restricted to one host including any non-default port, so example.com:8443 and example.com cannot share a sitemap even though they share a hostname. Third, per Google's sitemap documentation, the protocol allows up to 50,000 URLs and 52,428,800 uncompressed bytes per file — limits a browser-based generator has to respect or intentionally lower.
List-to-XML vs Crawler-Type Generators: How They Differ
Sitemap generators fall into two broad camps, and the difference shapes what you have to do before you run them. The table below compares the responsibilities of each approach.
| Aspect | List-to-XML generator | Crawler-type generator |
|---|---|---|
| Where the URL list comes from | You paste or supply it | The tool discovers it by fetching pages |
| Network calls | None — runs entirely on the URLs given | Yes — requests each page to find more links |
| lastmod discovery | Not available — you supply a shared value | Often read from HTTP headers or page metadata |
| Risk of low-quality URLs in output | Only what you reviewed | Anything reachable, including tags, archives, internal search |
| Typical use case | Hand-curated sites, migrations, reviewed URL lists | Large sites where manual review is impractical |
| Typical environment | Browser-based utility, no upload | Server-side crawler or hosted SaaS |
The XML Sitemap Generator sits firmly in the first column. If you've already audited which URLs belong in your sitemap — say after a migration, after pruning tag pages, or after consolidating redirect chains — a list-to-XML tool is the natural finishing step. If you haven't done that audit, a crawler will dump everything it can reach into the file, including pages you'd rather not expose.
The Processing Pipeline Behind a List-to-XML Generator
Behind the simple "paste and generate" interface sits a small, strict pipeline. Understanding it helps you diagnose errors and predict exactly which inputs will produce which output.
The first stage is line splitting. The tool splits the input on LF, CRLF, or CR line endings and ignores only lines that contain nothing but whitespace. Leading or trailing whitespace on a nonblank line is treated as an error rather than silently trimmed, so a stray space at the end of a URL will fail generation rather than be forgiven.
The second stage is URL validation. Each nonblank line must be an absolute HTTP or HTTPS URL after serialization by the browser's URL parser. FTP URLs, relative paths, bare hostnames, fragments, embedded credentials, raw control characters, and malformed percent escapes are rejected. This is what keeps a single fetched resource from spawning multiple sitemap entries (the fragment rule) and prevents a username and password from being published into a public file (the credential rule).
The third stage is normalization, governed by the WHATWG URL Standard. The browser parser lowercases the host, removes default ports, adds the required root slash, and percent-encodes non-ASCII characters. Valid existing percent escapes stay as escapes. After normalization, deduplication runs in first-seen order: the first occurrence of any URL wins, every later match increments a duplicate counter, and duplicate lines do not consume output slots.
The fourth stage is XML escaping and emission. The five XML entities — ampersand, apostrophe, quotation mark, greater-than, and less-than — are escaped, with ampersand processed first so newly created entities are not themselves re-escaped. The file begins with a UTF-8 declaration and the official urlset namespace. Final size is measured with TextEncoder against the exact byte budget, and the tool either accepts the file as-is or fails it outright — no truncated preview, no ellipsis.
Every step runs in the current browser tab. URLs and generated XML never leave the page, and the download is produced from a temporary Blob URL owned by the current result. Editing any input or option revokes the previous download before the next generation runs, so there is no stale file risk.
How to Build a sitemap.xml From a Reviewed URL List
Once you have a clean list of URLs you actually want indexed, the practical steps with the XML Sitemap Generator are short:
- Open the tool and paste one absolute HTTP or HTTPS URL per line into the URL list field. Use only one host — including any non-default port — per file.
- Decide whether you need optional metadata. Leave the lastmod, changefreq, and priority fields blank for a loc-only file. If you fill any of them in, the value will apply to every URL in the file, so use them only when a single shared value is truthful across the entire list.
- For lastmod, supply a real Gregorian date in YYYY-MM-DD form or a complete date-time with seconds and either Z or a valid UTC offset. Calendar dates, leap years, clock ranges, and timezone limits are checked, so a modification date you can't honestly justify shouldn't be invented.
- For changefreq, pick one of the seven protocol values: always, hourly, daily, weekly, monthly, yearly, or never. For priority, supply a decimal between 0.0 and 1.0. These are hints, not crawl commands.
- Click generate. Review the displayed XML and the URL counts. The first-seen order of unique URLs is the order in the output; duplicates increment a counter without adding entries.
- When the XML looks right, download sitemap.xml and publish it on the same host it represents. Invalid optional metadata fails the whole generation rather than being quietly dropped, so a clean result means every entry passed validation.
Optional Metadata: Shared Values, Not Per-URL Truth
The sitemap protocol's three optional fields are easy to misuse, because the tool applies one shared value to every URL when you supply any of them. There is no per-entry override, so the value has to be defensible for the entire file.
| Field | Allowed values per the protocol | What happens if invalid |
|---|---|---|
| lastmod | YYYY-MM-DD, or a complete date-time with seconds and Z or a UTC offset | Generation fails entirely |
| changefreq | always, hourly, daily, weekly, monthly, yearly, never | Generation fails entirely |
| priority | Decimal from 0.0 through 1.0 | Generation fails entirely |
The practical guidance is to leave all three blank unless a single shared value is genuinely true. A site-wide "weekly" changefreq for a blog where some posts change daily and others stay static for a year is misleading; omitting the field is more honest. The same applies to priority, which the protocol itself describes as a hint relative to your own pages rather than a ranking lever. For deeper rules on optional fields and the single-host constraint, the XML Sitemap Generator Cheat Sheet: Rules and Limits guide covers them case by case.
Why This Tool's Limits Sit Below the Protocol Maxima
The protocol permits 50,000 URLs and 52,428,800 uncompressed bytes per file. This tool uses smaller numbers: 10,000 unique URLs and 10,485,760 bytes of UTF-8 XML. The relationship is exact — 10 × 1,048,576 = 10,485,760 bytes, which is 10 mebibytes in binary terms — so the tool's byte budget is one-fifth of the protocol maximum, and the URL cap is one-fifth as well. The input side adds a third ceiling of 5,000,000 UTF-16 code units of source text.
The reason is practical rather than restrictive. A browser tab has to fit the parsed list, the serialized XML, the preview, and the final Blob all in memory at once. The protocol maxima are sized for server-side generators that stream a file to disk; a browser utility needs a hard ceiling that bounds preview rendering and Blob allocation without pretending to be the protocol itself. Every limit is all-or-nothing: the 10,000th unique URL is accepted and the next unique URL fails; the exact 10,485,760th byte is accepted and one byte more is rejected. No truncated preview, no ellipsis, no partial download — a failure means the file was not produced at all.
If you need a bigger file than the browser-side tool can produce, the options are to split the URL set across multiple sitemaps under a sitemap index, or to move to a server-side workflow. The tool makes no claim about being the largest possible generator; it claims to be a strictly bounded one that fails honestly when the bound is exceeded.
If you're weighing options, Compare A Then B vs B Then A in a Keyword Combiner covers this in detail.