URL

Normalisiert

Was ist der URL-Normalisierer?

Zwei URLs, die "dasselbe" sind, wegen Groß-/Kleinschreibung oder Query-Reihenfolge aber als ungleich verglichen werden — das ist einer dieser Bugs, die einen halben Nachmittag fressen. HTTPS://Example.com/page und https://example.com/page zeigen auf dieselbe Ressource, ein String-Vergleich sagt aber, sie unterscheiden sich. Der Normalisierer nimmt eine URL und erzeugt ihre kanonische Form gemäß RFC 3986 §6 und dem WHATWG URL Standard, sodass zwei URLs mit derselben Bedeutung denselben String ergeben.

Die Normalisierungen sind die langweiligen-aber-wichtigen: Schema und Host kleinschreiben (laut RFC 3986 §6.2.2.1 sind die case-insensitive), Standardports entfernen (:443 bei https, :80 bei http), prozentkodierte unreserved-Zeichen dekodieren (%41 → A), Query-Parameter alphabetisch nach Schlüssel sortieren, ein leeres Fragment streichen (# ohne etwas dahinter) und ./..-Pfadsegmente auflösen. Das Ausgabe-JSON enthält die normalisierte URL, das Original und ein changes-Array, das jede Umschreibung exakt auflistet — so siehst du, warum zwei scheinbar verschiedene URLs in Wahrheit identisch sind.

Alles läuft in deinem Browser über die Standard-URL-API und URLSearchParams — kein Server, kein Logging. Ist deine Eingabe schon kanonisch, ist das changes-Array leer und das ist die Antwort: nichts zu tun. Praktisch als Sanity-Check, bevor du eine sitemap veröffentlichst oder <link rel="canonical"> setzt.

So benutzt du den URL-Normalisierer

Drei Schritte. Jeder entspricht einem Button auf dieser Seite.

URL einfügen oder Beispiel laden

URL ins linke Panel kippen. Klick auf Beispiel, um eine realistisch chaotische URL zu laden — Schema und Host in Großbuchstaben, Standardport, durcheinandergewürfelte Query-Reihenfolge, prozentkodiertes Leerzeichen, leeres Fragment. Beispiel-URL:

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

Internationalisierte Domainnamen (IDN) werden vom URL-Konstruktor nach Punycode konvertiert — das ist die Form, die tatsächlich übers Netz geht, gemäß den Regeln zur URI-Normalisierung. Userinfo (user:pass@host) bleibt erhalten, falls vorhanden.

Ausgabe lesen

Das rechte Panel zeigt JSON mit drei Feldern: normalized (die kanonische URL), original (was du eingefügt hast, getrimmt) und changes — ein Array von { rule, from, to }-Einträgen, das jede Umschreibung auflistet. Ist changes leer, war die URL bereits kanonisch.

Kopieren oder herunterladen

Klick auf Kopieren, um das JSON in die Zwischenablage zu legen, oder auf Herunterladen, um es als .json-Datei zu speichern. Minifizieren drückt das JSON auf eine Zeile. Leeren im Eingabe-Panel setzt zurück.

Wann du das wirklich brauchst

Cache-Keys und Analytics-Deduplizierung

Dein Analytics-Dashboard sieht Example.com/page und example.com/page als zwei verschiedene Zeilen. Dein CDN-Cache auch. Beim Reinkommen normalisieren — Duplikat weg. Gleicher Trick beim Bauen eines URL-Shorteners oder einer Bookmark-Deduplizierung: speichere die normalisierte Form als Lookup-Key.

Kanonische URLs für SEO

Suchmaschinen bestrafen doppelte Inhalte, wenn dieselbe Seite über mehrere URLs erreichbar ist. Dein <link rel="canonical">-Tag und die URLs in deiner sitemap.xml sollten zu einer einzigen normalisierten Form passen. Googles Canonicalization-Leitfaden erklärt die Regeln; dieses Tool ist der schnellste Weg, sie von Hand anzuwenden.

Zwei URLs auf Gleichheit vergleichen

Du schreibst einen Redirect-Loop-Detektor oder testest einen Webhook. Zwei URLs sind "gleich", wenn ihre normalisierten Formen übereinstimmen. Vergleiche Strings nach dem Normalisieren — bastel keine eigene Gleichheitsfunktion auf Basis von URL.toString(), weil die weder Query-Parameter sortiert noch Standardports entfernt.

URLs vor Speicherung oder Anzeige säubern

Ein Nutzer fügt HTTPS://www.SHOP.com:443/cart/?b=2&a=1# in dein Formular ein. Das willst du nicht so in der Datenbank haben und ganz sicher nicht per E-Mail zurückschicken. Erst normalisieren, dann die saubere Form speichern. Kundenseitige URLs werden vorhersagbar.

Häufige Fragen

Was, wenn meine URL schon kanonisch ist?

Du siehst dieselbe URL in normalized wie in original, und das changes-Array ist leer ("changes": []). Das ist die Antwort — es gab nichts umzuschreiben. Die Seite wirft in dem Fall keine Exception und zeigt keinen Fehler.

Wird der Pfad über das Entfernen der trailing-Slash an der Wurzel hinaus angefasst?

Meistens nicht. .- und ..-Pfadsegmente werden aufgelöst (der URL-Konstruktor erledigt das automatisch — RFC 3986 §5.2.4 nennt das "remove dot segments"). Trailing-Slashes werden nur entfernt, wenn der Pfad nur / ist; /v1/orders/ bleibt /v1/orders/, weil RFC 3986 sagt, dass Trailing-Slashes signifikant sein können. Server-Frameworks behandeln sie ggf. als andere Routen.

Warum werden meine Query-Parameter sortiert? Mir war die Reihenfolge wichtig.

In RFC 3986 ist die Query-Reihenfolge semantisch nicht signifikant — ?a=1&b=2 und ?b=2&a=1 sind auf URL-Ebene äquivalent. Alphabetisches Sortieren liefert eine stabile kanonische Form, sodass zwei äquivalente URLs Byte für Byte übereinstimmen. Hängt deine Anwendung tatsächlich von der Parameterreihenfolge ab (sollte sie nicht, aber Legacy-Systeme tun das), bricht dieser Normalisierer diese Annahme — normalisiere keine URLs, die in einen Server gehen, dem die Reihenfolge wichtig ist.

Warum wird %20 nach der Normalisierung manchmal zu +?

Sowohl %20 als auch + bedeuten ein Leerzeichen innerhalb eines Query-Strings (nach den Regeln von application/x-www-form-urlencoded, was URLSearchParams zur Serialisierung benutzt). Wenn das URLSearchParams-Objekt die Query neu serialisiert, nutzt es +. Für jeden standardkonformen URL-Parser sind die beiden semantisch identisch; behandelt dein Server sie unterschiedlich, ist das ein Server-Bug.

Was passiert mit internationalisierten Domains wie café.example?

Der URL-Konstruktor wandelt den Host in Punycode um — caf%C3%A9.example wird zu xn--caf-dma.example. Das ist die Form, in der die URL tatsächlich über DNS gesendet würde, und das ist es, was RFC 3987 / die WHATWG-Spec festlegen. Der Wikipedia-Artikel zur URI-Normalisierung erklärt das IDN-Handling im Detail.

Ist das sicher für URLs mit Zugangsdaten (user:pass@host)?

Das Parsen passiert komplett in deinem Browser — nichts wird irgendwohin gesendet. Userinfo bleibt durch die Normalisierung erhalten. Ob du Zugangsdaten überhaupt in einer URL übergeben solltest, ist eine andere Frage — die meisten Browser und HTTP-Clients entfernen oder warnen heute bei userinfo wegen der Sicherheitsrisiken, und ein Authorization-Header ist meistens die bessere Wahl.

Werden doppelte Query-Parameter entfernt?

Nein. ?tag=red&tag=red bleibt ?tag=red&tag=red. Wiederholte Schlüssel können bedeutsam sein (manche APIs nutzen sie für Arrays), und Duplikate zu entfernen würde die Semantik ändern. Die Sortierung ist stabil, daher bleibt innerhalb desselben Schlüssels die ursprüngliche Reihenfolge erhalten.

Weitere URL- und JSON-Tools

Normalisieren ist eine Operation. Das hier passt natürlich dazu: