URL

Genormaliseerd

Wat is de URL Normalizer?

Twee URL's die "hetzelfde" zijn maar bij vergelijking niet gelijk uitvallen door hoofdletters of queryvolgorde — dat is zo'n bug die je halve middag opvreet. HTTPS://Example.com/page en https://example.com/page wijzen naar dezelfde resource, maar een stringvergelijking zegt dat ze verschillen. De normalizer neemt een URL en produceert de canonieke vorm volgens RFC 3986 §6 en de WHATWG URL Standard, zodat twee URL's die hetzelfde betekenen dezelfde string opleveren.

De normalisaties zijn de saaie-maar-belangrijke: schema en host in kleine letters (volgens RFC 3986 §6.2.2.1 zijn die hoofdletterongevoelig), standaardpoorten weghalen (:443 bij https, :80 bij http), percent-encoded niet-gereserveerde tekens decoderen (%41 → A), queryparameters alfabetisch sorteren op sleutel, een leeg fragment strippen (# zonder iets erachter) en . / ..-padsegmenten oplossen. De output-JSON bevat de genormaliseerde URL, de originele en een changes-array die precies opsomt wat herschreven is — je ziet zo waarom twee URL's die er anders uitzagen feitelijk gelijk zijn.

Alles draait in je browser via de standaard URL-API en URLSearchParams — geen server, geen logs. Als je invoer al canoniek is, is de changes-array leeg en dat is het antwoord: niets te doen. Handig als sanity check voor je een sitemap publiceert of <link rel="canonical"> zet.

Hoe je de URL Normalizer gebruikt

Drie stappen. Elke stap matcht met een knop op deze pagina.

Plak een URL of laad het voorbeeld

Gooi een URL in het linkerpaneel. Klik Voorbeeld om een realistisch rommelige URL te laden — schema en host in hoofdletters, standaardpoort, queryvolgorde door elkaar, percent-encoded spatie, leeg fragment. Voorbeeld-URL:

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

Geïnternationaliseerde domeinnamen (IDN) worden door de URL-constructor naar Punycode omgezet — dat is de vorm die feitelijk over het netwerk gaat, conform de regels van URI-normalisatie. Userinfo (user:pass@host) blijft behouden als het aanwezig is.

Lees de output

Het rechterpaneel toont JSON met drie velden: normalized (de canonieke URL), original (wat je plakte, getrimd) en changes — een array met { rule, from, to }-items met elke herschrijving. Is changes leeg, dan was de URL al canoniek.

Kopieer of download

Klik Kopiëren om het JSON naar je klembord te sturen, of Downloaden om het als .json-bestand op te slaan. Minificeren drukt het JSON op één regel. Met Wissen in het invoerpaneel begin je opnieuw.

Wanneer je dit echt gaat gebruiken

Cache-keys en analytics-deduplicatie

Je analytics-dashboard ziet Example.com/page en example.com/page als twee verschillende rijen. Je CDN-cache ook. Normaliseer aan de poort en het duplicaat verdwijnt. Zelfde truc als je een URL-shortener of bookmark-deduplicator bouwt — sla de genormaliseerde vorm op als lookup-key.

Canonieke URL's voor SEO

Zoekmachines straffen dubbele content af als dezelfde pagina via meerdere URL's bereikbaar is. Je <link rel="canonical">-tag en de URL's in je sitemap.xml moeten matchen op één genormaliseerde vorm. Google's canonicalization-documentatie beschrijft de regels; deze tool is de snelste manier om ze handmatig toe te passen.

Twee URL's vergelijken op gelijkheid

Je schrijft een redirect-loop-detector of test een webhook. Twee URL's zijn "hetzelfde" als hun genormaliseerde vorm matcht. Vergelijk strings na normaliseren — bouw geen eigen gelijkheidsfunctie op basis van URL.toString(), want die sorteert geen queryparameters en haalt geen standaardpoorten weg.

URL's opschonen voor opslag of weergave

Een gebruiker plakt HTTPS://www.SHOP.com:443/cart/?b=2&a=1# in je formulier. Dat wil je niet zo in je database, en zeker niet zo terugmailen. Eerst normaliseren, dan de schone vorm bewaren. URL's die klanten zien worden voorspelbaar.

Veelgestelde vragen

Wat als mijn URL al canoniek is?

Je ziet dezelfde URL in normalized als in original en de changes-array is leeg ("changes": []). Dat is het antwoord — er was niets te herschrijven. De pagina gooit geen exception en toont geen fout in dat geval.

Wordt het pad aangepast buiten het verwijderen van de afsluitende slash van de root?

Bijna niet. . en ..-padsegmenten worden opgelost (de URL-constructor doet dat automatisch — RFC 3986 §5.2.4 noemt dat "remove dot segments"). Afsluitende slashes worden alleen weggehaald als het pad enkel / is; /v1/orders/ blijft /v1/orders/ omdat RFC 3986 zegt dat afsluitende slashes betekenisvol kunnen zijn. Server-frameworks behandelen ze soms als andere routes.

Waarom worden mijn queryparameters gesorteerd? De volgorde was belangrijk.

In RFC 3986 is de queryvolgorde semantisch niet relevant — ?a=1&b=2 en ?b=2&a=1 zijn equivalent op URL-niveau. Alfabetisch sorteren geeft een stabiele canonieke vorm zodat twee equivalente URL's byte-voor-byte matchen. Hangt je applicatie echt af van parametervolgorde (zou niet, maar legacy-systemen doen het), dan breekt deze normalizer die aanname — normaliseer geen URL's die naar een server gaan die om de volgorde geeft.

Waarom wordt %20 soms een + na normalisatie?

Zowel %20 als + betekenen een spatie binnen een querystring (volgens de regels van application/x-www-form-urlencoded, wat URLSearchParams gebruikt voor serialisatie). Als het URLSearchParams-object de query opnieuw serialiseert, gebruikt het +. Voor elke standaardconforme URL-parser zijn ze semantisch identiek; behandelt jouw server ze anders, dan zit de bug in de server.

Wat gebeurt er met geïnternationaliseerde domeinen zoals café.example?

De URL-constructor zet de host om naar Punycode — caf%C3%A9.example wordt xn--caf-dma.example. Dat is de vorm waarmee de URL feitelijk over DNS gaat, en is wat RFC 3987 / de WHATWG-spec voorschrijven. Het Wikipedia-artikel over URI-normalisatie behandelt de IDN-afhandeling als je de details wilt.

Is het veilig met URL's met credentials (user:pass@host)?

Het parsen gebeurt volledig in je browser — er gaat niets ergens heen. Userinfo blijft behouden tijdens normalisatie. Of je überhaupt credentials in een URL zou moeten meegeven is een ander verhaal — de meeste browsers en HTTP-clients halen userinfo tegenwoordig weg of waarschuwen erover vanwege beveiligingsrisico's, en een Authorization-header is doorgaans beter.

Worden dubbele queryparameters verwijderd?

Nee. ?tag=red&tag=red blijft ?tag=red&tag=red. Herhaalde sleutels kunnen betekenis hebben (sommige API's gebruiken ze voor arrays) en duplicaten weghalen zou de semantiek veranderen. De sortering is stabiel, dus binnen dezelfde sleutel blijft de oorspronkelijke volgorde behouden.

Andere URL- en JSON-tools

Normaliseren is één bewerking. Dit past er natuurlijk bij: