URL

Normalized

What is the URL Normalizer?

Two URLs that are "the same" but compare-not-equal because of casing or query order is one of those bugs that wastes an afternoon. HTTPS://Example.com/page and https://example.com/page resolve to the same resource, but a string comparison says they differ. The normalizer takes a URL and produces its canonical form per RFC 3986 §6 and the WHATWG URL Standard, so two URLs that mean the same thing produce the same string.

The normalizations are the boring-but-important ones: lowercase the scheme and host (per RFC 3986 §6.2.2.1, those are case-insensitive), drop default ports (:443 on https, :80 on http), decode percent-encoded unreserved characters (%41 → A), sort query parameters alphabetically by key, strip an empty fragment (# with nothing after it), and collapse . / .. path segments. The output JSON includes the normalized URL, the original, and a changes array listing exactly what was rewritten — so you can see why two URLs that looked different are actually the same.

Everything runs in your browser using the standard URL API and URLSearchParams — no server, no logging. If your input is already canonical, the changes array is empty and that's the answer: nothing to do. Useful as a sanity check before you publish a sitemap or set <link rel="canonical">.

How to Use the URL Normalizer

Three steps. Each one matches a button on this page.

Paste a URL or Load the Sample

Drop a URL into the left panel. Click Sample to load a realistic messy URL — uppercase scheme and host, default port, scrambled query order, percent-encoded space, empty fragment. Example URL:

HTTPS://API.Shop.Example.com:443/v1/orders/?status=active&customer=Ava%20Chen&page=2#

Internationalized domain names (IDN) are converted to Punycode by the URL constructor — that's the form actually sent over the wire, per URI normalization rules. Userinfo (user:pass@host) is preserved if present.

Read the Output

The right panel shows JSON with three fields: normalized (the canonical URL), original (what you pasted, trimmed), and changes — an array of { rule, from, to } entries listing every rewrite. If changes is empty, the URL was already canonical.

Copy or Download

Click Copy to send the JSON to your clipboard, or Download to save it as a .json file. Minify compacts the JSON onto one line. Use Clear on the input panel to start over.

When You'd Actually Use This

Cache keys and analytics dedup

Your analytics dashboard sees Example.com/page and example.com/page as two different rows. So does your CDN cache. Normalize on the way in and the duplicate goes away. Same trick if you're building a URL-shortener or bookmark dedupe — store the normalized form as the lookup key.

Canonical URLs for SEO

Search engines penalize duplicate content when the same page is reachable at multiple URLs. Your <link rel="canonical"> tag and your sitemap.xml URLs should match a single normalized form. Google's canonicalization guidance spells out the rules; this tool is the quickest way to apply them by hand.

Comparing two URLs for equality

You're writing a redirect-loop detector or testing a webhook. Two URLs are "the same" if their normalized forms match. Compare strings after normalizing — don't roll your own equality function based on URL.toString(), because that doesn't sort query params or drop default ports.

Cleaning URLs before storage or display

A user pastes HTTPS://www.SHOP.com:443/cart/?b=2&a=1# into your form. You don't want to store that in your database, and you definitely don't want to email it to them. Normalize first, then save the clean form. Customer-facing URLs become predictable.

Common Questions

What if my URL is already canonical?

You'll see the same URL in normalized as in original and the changes array will be empty ("changes": []). That's the answer — there was nothing to rewrite. The page does not throw or show an error in that case.

Does it touch the path beyond removing trailing slashes from the root?

Mostly no. . and .. path segments are resolved (the URL constructor does this automatically — RFC 3986 §5.2.4 calls it "remove dot segments"). Trailing slashes are only stripped when the path is just /; /v1/orders/ stays as /v1/orders/ because RFC 3986 says trailing slashes can be significant. Server frameworks may treat them as different routes.

Why are my query parameters being sorted? I cared about the order.

In RFC 3986, query order is not semantically significant — ?a=1&b=2 and ?b=2&a=1 are equivalent at the URL level. Sorting alphabetically gives you a stable canonical form so two equivalent URLs match byte-for-byte. If your application actually depends on parameter order (it shouldn't, but legacy systems do), this normalizer will break that assumption — don't normalize URLs you're feeding into a server that cares about order.

Why does %20 sometimes become + after normalization?

Both %20 and + mean a space inside a query string (per the application/x-www-form-urlencoded rules, which is what URLSearchParams uses for serialization). When the URLSearchParams object re-serializes the query, it uses +. They're semantically identical to any standards-compliant URL parser; if your server treats them differently, that's a bug in the server.

What happens to internationalized domains like café.example?

The URL constructor converts the host to Punycode — caf%C3%A9.example becomes xn--caf-dma.example. That's the form the URL would actually be sent in over DNS, and it's what RFC 3987 / the WHATWG spec specify. Wikipedia's URI normalization article walks through the IDN handling if you want the gory details.

Is this safe for URLs with credentials (user:pass@host)?

Parsing happens entirely in your browser — nothing is sent anywhere. Userinfo is preserved through normalization. Whether you should be passing credentials in a URL at all is a different question — most browsers and HTTP clients now strip or warn on userinfo because of the security risks, and you're generally better off with an Authorization header.

Does it remove duplicate query parameters?

No. ?tag=red&tag=red stays as ?tag=red&tag=red. Repeated keys can be meaningful (some APIs use them for arrays), and removing duplicates would change semantics. The sort is a stable sort, so within the same key the original order is preserved.

Other URL & JSON Tools

Normalizing is one operation. Here's what else pairs naturally with it: