Wat deze tool doet
Dit is een URL-decoder en een querystring-parser in één pagina. Plak een link van willekeurige lengte — een omleiding uit een e-mail, een callback-URL van een OAuth-flow, een regel uit een serverlog, een trackinglink met dertig aan elkaar geplakte parameters — klik op Decoderen, en er komen twee dingen terug. De hele tekenreeks wordt omgezet van percent-gecodeerde tekst naar leesbare tekst, en als er een querystring in zit, wordt elke parameter daarin eronder uitgezet als een tabel met de sleutel in de ene kolom en de waarde in de volgende.
De tabel is het onderdeel dat tijd bespaart. Een querystring is één doorlopende reeks tekens waarin de grenzen worden gemarkeerd door twee leestekens die er precies hetzelfde uitzien als alle andere tekens eromheen, en de vierde parameter met het blote oog vinden betekent ampersands tellen. Opgesplitst in rijen beantwoordt dezelfde querystring in één oogopslag welke parameters aanwezig zijn, welke leeg zijn, en welke ene de verkeerde waarde draagt.
Elke decodering verschijnt boven de vorige, zodat twee versies van een link vergeleken kunnen worden zonder de eerste kwijt te raken. "Kopiëren" geeft de gedecodeerde tekst terug; "Link kopiëren" geeft een link naar deze pagina terug met de URL die je geplakt hebt er al in, zodat een collega die die link opent dezelfde decodering ziet zonder dat jij hoeft uit te leggen welke link je bedoelde. Resultaten kunnen één voor één worden verwijderd of in één keer gewist, en niets overleeft een herlaad.
Wat percent-codering is, en waarom URL's het gebruiken
Een URL mag alleen een kleine, vaste verzameling tekens bevatten: letters, cijfers, een handvol tekens zoals het koppelteken en de punt, en enkele leestekens die structurele betekenis dragen — de schuine streep die padsegmenten scheidt, het vraagteken dat de query opent, de ampersand die parameters scheidt, het isgelijkteken dat een sleutel van zijn waarde splitst, het hekje dat het fragment start. Al het andere moet gecodeerd worden, en dat geldt ook voor elk van die structurele tekens wanneer het als data bedoeld is in plaats van als structuur.
De codering is bewust eenvoudig. Het teken wordt omgezet naar zijn bytes in UTF-8, en elke byte wordt geschreven als een procentteken gevolgd door twee hexadecimale cijfers. Een spatie wordt %20. Een schuine streep binnen een waarde wordt %2F. Een ampersand die bij de data hoort wordt %26, en dat is precies wat voorkomt dat hij gelezen wordt als het begin van de volgende parameter. Alles buiten ASCII kost meer dan één escape: de é in café is twee bytes en dus %C3%A9, en een emoji is er vier.
Decoderen keert dat om, en het is een mechanische bewerking zonder ruimte voor interpretatie — daarom kun je een decoder vertrouwen om exact te zijn. Wat je terugkrijgt is de tekenreeks die de afzender bedoelde, in plaats van de tekenreeks die de URL verplicht moest dragen.
De querystring-tabel, en waarom de volgorde van bewerkingen ertoe doet
Alles na het eerste vraagteken, tot aan het fragment, is de querystring. Conventie — niet de specificatie — zegt dat het een lijst is van sleutel-waardeparen, gescheiden door ampersands, elk paar gesplitst bij het eerste isgelijkteken. Dat is de conventie die deze pagina volgt: splitsen op de ampersand om één rij per parameter te krijgen, elke rij splitsen bij zijn eerste isgelijkteken om de twee kolommen te krijgen.
De volgorde van die stappen is geen detail, en die omdraaien is de meest voorkomende fout in zelfgebouwde URL-parsers. Het splitsen moet gebeuren op de gecodeerde tekst, vóórdat er iets gedecodeerd wordt. Neem een zoekparameter met als waarde café & bar: gecodeerd is de ampersand daarin %26 en kan niet verward worden met een scheidingsteken. Decodeer eerst de hele query en die %26 wordt een echte ampersand, waardoor het splitsen vervolgens twee parameters oplevert waar de afzender er één stuurde, en de waarde stilletjes alles na de ampersand verliest. Dezelfde valkuil geldt voor een isgelijkteken binnen een waarde, en daarom wordt er alleen bij het eerste isgelijkteken gesplitst — een base64-waarde die eindigt op opvulling, of een geneste URL met zijn eigen query, zou anders doormidden gesneden worden.
Een parameter zonder isgelijkteken is legaal en redelijk gebruikelijk als vlag. Hij verschijnt in de tabel met zijn sleutel en een waarde gemarkeerd als leeg, in plaats van weggelaten te worden, want een vlag die aanwezig is, is iets anders dan een vlag die afwezig is.
Je URL verlaat je browser nooit
Niets wat je hier plakt wordt een netwerkverzoek. Het decoderen gebeurt door je eigen browser, de tabel wordt in de pagina opgebouwd, en de tekst wordt alleen in het geheugen bewaard — niets wordt naar een server gepost, in een cookie geschreven of in lokale opslag bewaard. Herladen wist elk resultaat, en het sluiten van het tabblad ruimt de gegevens op.
Een URL lijkt het minst gevoelige wat je waar dan ook zou kunnen plakken, en is regelmatig juist het meest gevoelige. Querystrings zijn de plek waar systemen sessie-ID's, wachtwoordherstel-tokens, ondertekende downloadlinks, API-sleutels toegevoegd door een lui geïntegreerd systeem, uitnodigingscodes, e-mailadressen en genoeg trackingparameters plaatsen om een specifieke persoon op een specifiek apparaat te identificeren. Een wachtwoordherstellink die geplakt wordt in een decoder die zijn invoer uploadt, is aan iemand overhandigd — en het herstel-token erin is meestal nog een uur geldig.
Omdat het decoderen in je browser gebeurt, speelt dat allemaal niet. Open je netwerktabblad terwijl je deze pagina gebruikt: afgezien van de analytics-beacon die de site bij elke paginalading verstuurt — een URL en een paginatitel — levert decoderen geen enkel verzoek op. Verbreek de netwerkverbinding volledig en de tool blijft werken, wat de enige demonstratie van de claim is die niet vraagt om iemand op zijn woord te geloven.
Plustekens, dubbele codering en de andere valkuilen
Drie dingen zorgen er regelmatig voor dat een gedecodeerde URL er verkeerd uitziet, en alle drie verdienen het om herkend te worden in plaats van uitgedebugd.
De eerste is het plusteken. In een querystring betekent een plus van oudsher een spatie, een overblijfsel van HTML-formulierverzending dat elk webframework nog steeds honoreert. Overal elders in een URL — in het pad, in het fragment — is een plus een letterlijke plus. Deze pagina volgt die splitsing exact: de tabel behandelt een plus in een parameter als een spatie, terwijl de volledige gedecodeerde tekenreeks erboven plustekens met rust laat. Als een waarde die zou moeten lezen als [email protected] terugkomt met een spatie, heeft de afzender hem verkeerd gecodeerd; een letterlijke plus in een queryvalue moet verstuurd worden als %2B.
De tweede is dubbele codering. Een URL die twee keer door een encoder is gegaan, toont %2520 waar een spatie zou moeten staan, omdat het procentteken van %20 zelf ook gecodeerd werd tot %25. Eén keer decoderen keert dat terug naar %20 in plaats van naar een spatie, wat op een kapotte decoder lijkt maar in werkelijkheid een accuraat verslag is van een kapotte link. Plak het resultaat er opnieuw in en decodeer nogmaals om het te bevestigen — en fix vervolgens de code die het twee keer codeerde, meestal een waarde die gecodeerd werd toen hij werd opgeslagen en nogmaals toen hij in een link werd gezet.
De derde is een misvormde escape: een kaal procentteken dat niet gevolgd wordt door twee hexadecimale cijfers, wat gebeurt zodra een URL is afgekapt door een logformaat of afgebroken door een regelafbreking. Een strikte decoder weigert dan de hele tekenreeks. Deze pagina decodeert in plaats daarvan de escapes die wel geldig zijn, laat de kapotte zichtbaar staan waar hij zit, en laat je de rest lezen — wat precies is wat je nodig had van een afgekapte logregel.
Een uitgewerkt voorbeeld
Neem een zoeklink met vijf parameters: een query van café + bar waarbij zowel het accent als de ampersand gecodeerd zijn, een categorie met een schuine streep erin, een paginanummer, een notitie met een procentteken erin, en een omleidingsdoel dat zelf een volledige URL is met zijn eigen query.
Gedecodeerd meldt de koptekst vijf parameters. De eerste rij toont q en café & bar — één parameter, niet twee, omdat het splitsen plaatsvond vóór het decoderen. De categorie-rij toont food/drink met zijn schuine streep hersteld, en de notitie toont 50% off, waarbij het procentteken alleen overleefde omdat het verstuurd werd als %25. De laatste rij bevat de geneste URL, compleet met het vraagteken en de ampersand van zijn eigen query — precies het geval dat een parser breekt die te vroeg decodeert. Klik op "Voorbeeld laden" om die link uit elkaar te zien vallen.
Nee. Niets van wat je plakt wordt verzonden: het decoderen en de tabel worden door je eigen browser gemaakt, en het resultaat bestaat alleen in de pagina voor je. Er is geen cookie, geen lokale opslag en geen logging van wat je plakt, en dat is ook waarom een herlaad de resultaten leegt.
Omdat een plusteken in een querystring een spatie betekent, een conventie geërfd van HTML-formulierverzending. De tabel volgt die regel, terwijl de volledige gedecodeerde tekenreeks boven de tabel plustekens onaangeroerd laat. Een letterlijke plus binnen een queryvalue moet gecodeerd verstuurd worden als %2B.
De URL is twee keer gecodeerd. Een spatie werd %20, en toen werd het procentteken van die escape zelf gecodeerd tot %25, wat %2520 oplevert. Eén keer decoderen geeft correct %20 terug. Decodeer het resultaat nog een keer om het te bevestigen, en fix daarna welke stap in je pijplijn een al-gecodeerde waarde opnieuw codeert.
Hij blijft staan zoals hij is en de rest van de tekenreeks wordt eromheen gedecodeerd. Een kaal procentteken dat niet gevolgd wordt door twee hexadecimale cijfers is niet geldig, en een strikte decoder wijst de hele invoer daarom af. Dat is niet handig voor een URL die door een log is afgekapt, dus deze pagina decodeert wat kan en toont je het kapotte deel op zijn plek.
Ja. Een tekenreeks zoals a=1&b=café%20bar zonder schema, host of vraagteken wordt herkend als een query en verwerkt in de tabel. Dat is meestal de vorm die een logregel of een debugger je geeft, en het is prima om die op zichzelf te plakken.
Ja, en het behoudt ze. Een query mag legaal een sleutel herhalen — een id die drie keer verstuurd wordt, een set filterwaarden — en elk voorkomen krijgt zijn eigen rij, in de volgorde waarin het verscheen. Er wordt niets samengevoegd of ontdubbeld, want welke herhaling een server honoreert is een beslissing van jouw server, niet een die een decoder voor je zou moeten nemen.
De volledige gedecodeerde tekenreeks bevat alles wat je geplakt hebt, fragment inbegrepen. De tabel dekt alleen de query, wat tussen het vraagteken en het hekje zit. Als jouw applicatie parameters na het hekje bewaart — zoals sommige single-page routers doen — plak dat deel dan apart en het wordt gelezen als een querystring.
Een link naar deze pagina die de URL draagt die je geplakt hebt, na het hekje, zodat het openen ervan het veld vult en opnieuw decodeert. Het hekje is bewust gekozen: een fragment is het enige deel van een URL dat een browser nooit naar een server stuurt, dus een gedeelde link houdt de belofte die de rest van de pagina doet. Zo'n link delen geeft de URL nog steeds aan wie je hem stuurt, dus behandel een link met een token zoals je het token zelf zou behandelen.
Nee, deze pagina decodeert. Coderen is de bewerking met de keuzes erin: welke tekens gecodeerd moeten worden hangt af van waar de waarde naartoe gaat, want een padsegment, een queryvalue en een formulierbody hebben elk andere regels, en een tool die raadt, zit vaak genoeg fout om nuttelozer te zijn dan niets.
Zodra de pagina geladen is, ja. Decoderen gebruikt de eigen ingebouwde functies van je browser, dus je kunt de verbinding verbreken en blijven werken — wat ook meteen het eenvoudigste bewijs is dat er niets wordt geüpload.