Normalising URLs in Bulk
Paste a list of URLs, one per line, and this tool normalises each one: hostnames lowercased, trailing slashes removed from paths, and a protocol added where one is missing. It reports how many entries it changed.
URL lists arrive messy. Exports from different tools use different conventions, hand-maintained spreadsheets accumulate inconsistencies, and pasting from several sources guarantees a mix. Normalising first makes everything downstream — deduplication, redirect mapping, sitemap generation — work properly.
What gets normalised
- Hostname lowercased — Example.COM becomes example.com. Hostnames are case-insensitive by specification, so this is always safe.
- Trailing slash removed from paths — /page/ becomes /page. The root path keeps its slash.
- Missing protocol added — example.com/page becomes https://example.com/page.
- Whitespace trimmed from each line.
What is deliberately left alone
Path case is preserved. Unlike hostnames, paths are case-sensitive on most servers, so /Products and /products may genuinely be different pages. Lowercasing them automatically could silently point your list at URLs that return 404.
Query strings are untouched, including their order and casing. Parameters frequently matter, and normalising them risks changing what the URL actually requests.
The protocol is not changed if one is already present. If your list mixes http and https, that is worth knowing about rather than having quietly unified — it usually indicates a redirect configuration worth checking.
Why trailing slashes matter
Search engines treat /page and /page/ as different URLs. Most sites serve identical content at both, which creates duplicate URLs and splits ranking signals unless one redirects to the other.
Which convention you use does not matter; consistency does. Pick one, make the server redirect the other, and make sure your internal links, sitemap and canonical tags all use the chosen form.
This tool strips trailing slashes as its convention. If your site standardises the other way, be aware the output will need the slashes restored — or normalise with a find-and-replace after running it.
Where this fits in a cleanup
Normalisation comes first, because deduplication depends on it. Two entries that differ only by hostname case are not recognised as duplicates by a naive comparison, so normalising before running the URL Deduplicator is what makes the deduplication actually work.
If your list contains campaign URLs, strip the tracking first with the URL Cleaner — otherwise every UTM variant survives as a distinct entry.
After deduplicating, confirm the URLs actually resolve. The Redirect Chain Checker will show whether an entry redirects, which matters because a sitemap should list final destinations only. Then generate the file with the Sitemap Generator.
Redirect mapping during a migration
The highest-stakes use of URL normalisation is a migration mapping — the spreadsheet pairing old URLs with new ones. Inconsistent formatting there produces rules that do not match the URLs people actually request.
A rule written for /Old-Page/ will not fire for a request to /old-page depending on your server's case handling, so a visitor arriving from an old external link gets a 404 instead of a redirect. Those failures are invisible until someone reports them or you notice the traffic gone.
Normalising both columns before building the rules removes a whole category of these. It is a five-minute step that prevents a class of problem that is genuinely painful to debug afterwards.
Invalid entries
Lines that cannot be parsed as URLs are returned unchanged rather than dropped. That is deliberate — silently removing entries from a list you are about to build redirects from would be worse than leaving something obviously broken in place for you to see.
If an entry comes back looking identical when you expected a change, it usually could not be parsed. Check for stray spaces, missing dots in the hostname, or characters that need encoding — the URL Encoder handles the last case.
Frequently asked questions
Why does it not lowercase the path?
Paths are case-sensitive on most servers, so /Products and /products can be genuinely different pages. Lowercasing automatically could point your list at URLs that return 404. Only the hostname, which is case-insensitive by specification, is lowercased.
Should URLs have trailing slashes?
Either convention is fine as long as you use one consistently and the server redirects the other. Search engines treat /page and /page/ as different URLs, so inconsistency creates duplicates.
Does it change http to https?
No. If a protocol is present it is preserved, because a mix of http and https in your list usually indicates a redirect configuration worth investigating rather than something to quietly unify. Missing protocols default to https.
What happens to URLs it cannot parse?
They are returned unchanged rather than removed. Dropping entries silently from a list you may be building redirects from would be more dangerous than leaving a visibly broken line for you to fix.
What order should I run the URL tools in?
Clean tracking parameters first, then normalise here, then deduplicate, then check for redirects, then generate your sitemap. Normalising before deduplicating is what lets the deduplicator recognise variants as the same page.