URL Parser & Builder
Parseer URLs in 8 componenten met query-tabel en IDN/Punycode-detectie. Bouw URLs uit delen. Relatieve resolver.
Resolved
Query parameters
| Key | Value |
|---|---|
No query parameters.
Over deze tool
URL Parser & Builder ontleedt elke URL in zijn acht RFC 3986-componenten — scheme, userinfo, host, port, path, query, fragment en de origineel-gecodeerde vorm — en presenteert ze in een bewerkbaar formulier. Wijzig een willekeurig veld en de samengestelde URL wordt direct bijgewerkt. De querystring wordt getoond als een tabel van naam/waarde-paren, met de juiste percent-codering toegepast op speciale tekens.
De tool behandelt ook de gerelateerde operaties: punycode/IDN-detectie op de host (een xn---label decodeert naar de Unicode-vorm, een Unicode-host codeert naar xn--), relatieve-URL-resolutie tegen een basis (pas ../foo?bar toe op https://example.com/a/b/c en krijg https://example.com/a/foo?bar), en validatie tegen de WHATWG URL-specificatie (die in sommige gebieden strikter is dan RFC 3986, met name authority-parsing).
Wanneer gebruikt u deze tool
- URL-behandeling debuggen. Een redirect die aankomt als
%25in plaats van%— vind de dubbele-codering-stap in uw stack. - Veilige links bouwen. Construeer URL's uit gebruikersinput met juiste escaping in plaats van stringconcatenatie.
- Een verdachte URL verifiëren. Decodeer verduisterde
%2E%2E-traversal-pogingen, IDN-homograph-trucs en userinfo-phishing duidelijk. - Werken met OAuth en redirects. Bevestig dat
redirect_uri-parameters correct gecodeerd zijn voordat de auth-server ze weigert.
Over percent-codering
RFC 3986 reserveert een handvol tekens met structurele betekenis (:/?#[]@!$&'()*+,;=). Binnen pad-segmenten en query-waarden moeten ze percent-gecodeerd worden wanneer ze als data verschijnen in plaats van syntax. Moderne URL-parsers doen dit automatisch; handmatige stringconcatenatie niet. Als u zich "?key=" + value in code ziet schrijven, heeft u vrijwel zeker een injection-bug — gebruik in plaats URLSearchParams of onze builder.
Veelgestelde vragen
Wat is het verschil tussen userinfo en het pad?
:// en de host: https://user:[email protected]/path. Het is technisch legaal in URL's maar Chrome / Firefox strippen het uit de adresbalk om phishing te voorkomen (https://[email protected]). Moderne HTTP-clients waarschuwen of weigeren het. Als u credentials in een URL nodig heeft, codeer ze correct en verkies in plaats Authorization-headers — userinfo in URL's is een beveiligingssmell.
Waarom komen mijn querystring-waarden terug met %20 in plaats van spaties?
%20 (percent-codering) of + (de oudere form-urlencoded-variant voor querystrings). Beide decoderen naar een spatie op de server. %20 is de universele vorm; + werkt alleen binnen querystrings, nooit in paden. Onze builder gebruikt overal %20 voor veiligheid.
Hoe werkt relatieve URL-resolutie?
./ en ../ in het resulterende pad. Voorbeelden: ../x toegepast op /a/b/c/d geeft /a/b/x; //other.com/path toegepast op iets geeft //other.com/path (een "scheme-relatieve" referentie). Onze tool draait dit algoritme en toont de geresolvede URL.
Detecteert de parser IDN-homograph-aanvallen?
xn---labels) en decodeert ze naar Unicode, zodat u kunt zien welke tekens werkelijk aanwezig zijn. Een "google.com" met een Cyrillische о in plaats van Latijnse o decodeert naar een Unicode-vorm die zichtbaar de lookalike bevat. Combineer met de Punycode-tool voor een diepere inspectie; moderne browsers tonen deze ook in de adresbalk.