URL-parser
Splits een URL in protocol, host, pad en queryparameters
Over deze tool
Plak een URL en zie hem ontleed: protocol, host, poort, pad, fragment en elke queryparameter als een gedecodeerde sleutel-waardetabel. Het gebruikt dezelfde WHATWG-URL-parser als je browser voor navigatie, dus de interpretatie die je ziet is de interpretatie die een browser daadwerkelijk toepast — inclusief randgevallen als het weglaten van standaardpoorten en het normaliseren van paden.
De tabel met queryparameters gebruik je het vaakst: lange OAuth-redirects, met analytics getagde links en API-aanroepen worden in één oogopslag leesbaar, met elke waarde al percent-gedecodeerd. Kale domeinen zonder schema worden ook geaccepteerd; voor het parsen wordt https:// aangenomen.
Het combineert vanzelf met de URL-encoder — parseer hier een URL om de parameter te vinden die je nodig hebt, pas de waarde aan, en codeer hem daar opnieuw.
Veelgestelde vragen
- Waarom verschilt de geparseerde URL licht van wat ik plakte?
- De WHATWG-parser normaliseert: hij zet schema en host in kleine letters, verwijdert standaardpoorten (:443 voor https), lost ./- en ../-padsegmenten op en codeert tekens die dat nodig hebben. Wat je ziet is de canonieke vorm waar servers en browsers het over eens zijn.
- Kan hij URL’s met dubbele querysleutels aan?
- Ja — elk voorkomen krijgt zijn eigen rij, in volgorde. Dubbele sleutels zijn legaal en gebruikelijk: veel API’s lezen ze als arrays (?tag=a&tag=b).
- Wat is het verschil tussen host en hostname?
- hostname is alleen het domein (example.com); host bevat ook een expliciete niet-standaardpoort (example.com:8080). Als de poort de standaard van het schema is, zien beide er hetzelfde uit omdat de poort wordt weggelaten.
- Wordt het fragment (#...) naar de server gestuurd?
- Nee. Alles na # blijft in de browser — servers zien het nooit. Daarom gebruikten single-page-apps het vroeger voor routing aan de clientzijde, en daarom zijn analytics-parameters achter # onzichtbaar voor de backend.