Wat betekenen «coderen» en «decoderen» van een URL?
Een URL coderen (« url encode », « urlencode ») zet elk verboden teken in een adres — spatie, accent, ampersand, plusteken — om naar een sequentie van een procent gevolgd door de twee hexadecimale cijfers van zijn byte. Een URL decoderen (« url decode », « decoder url ») leest deze sequenties omgekeerd: de bytes worden hersteld en vervolgens omgezet naar tekens volgens de opgegeven codering, meestal UTF-8. Dat koppel is precies wat mensen zoeken wanneer ze «encoder decoder url» of «percent encoding online» intypen.
Percent-encoding is geen compressie en geen versleuteling: een woord met accent wordt twee keer zo lang en iedereen kan het met het blote oog lezen. De enige rol is om elke byte door een URL te krijgen, die standaard slechts een deelverzameling van ASCII toestaat. Omgekeerd dient Base64 om bytes over volledig tekstuele kanalen te transporteren — de twee lijken visueel op elkaar maar zijn niet uitwisselbaar.
Hoe codeer je een URL in percent-encoding
Stap 1: de tekst wordt eerst omgezet in bytes volgens het gekozen tekenset, standaard UTF-8. Stap 2: voor elke byte wordt gekeken of het bijbehorende teken in de lijst met toegestane tekens voor het gekozen bereik staat. Stap 3: hoort het ertoe, dan wordt het ongewijzigd overgenomen; anders wordt het %XX, waarbij XX de twee hexadecimale cijfers van de byte zijn. Stap 4: is de optie spatie als + actief, dan wordt byte 32 vervangen door een plusteken in plaats van %20.
Voorbeeld: « café & été » in het bereik component geeft caf%C3%A9%20%26%20%C3%A9t%C3%A9. Typ die tekst gewoon in de encoder: het resultaat, de invoeromvang, de uitvoeromvang en de meerkost verschijnen nog voordat je de toets loslaat.
De vier coderingsbereiken
Het componentbereik bewaart alleen letters, cijfers en - _ . ! ~ * ' ( ) : dat is de waarde van een parameter en die hoort bij encodeURIComponent. De querystring bewaart bovendien de ampersands en gelijktekens, om een hele query string opnieuw op te bouwen. Het padsegment staat / : @ & = + $ , ; toe om de schuine streepjes niet te breken. De Volledige URL voegt nog ?, #, [ en ] toe: bijna niets wordt geëscaped, alleen spaties en niet-ASCII-tekens gaan naar %XX.
Hoe decodeer je een gecodeerde URL
Het decoderen scant de string van links naar rechts: een procent gevolgd door twee hexadecimale cijfers levert een byte op, elk ander teken wordt na conversie volgens de gekozen codering overgenomen. De bytes worden vervolgens gegroepeerd en omgezet naar tekens — twee bytes voor « é », drie voor « 日 », vier voor een emoji. Het tabblad «Decoderen» toont elke gevonden sequentie, de positie in de string, de bytes en de bijbehorende tekst.
Als het procent niet wordt gevolgd door twee geldige cijfers, is de fout duidelijk: onvolledige sequentie of ongeldig hexadecimaal teken. De knop «%-tekens corrigeren» zet losse procenttekens om in %25, waardoor de string decodeerbaar blijft zonder informatie te verliezen — de veiligste optie voor een gedeeltelijk geëscapede URL.
Spatie: %20 of + — de regel voor formulieren
%20 is de spatie in strikte percent-encoding: die werkt in het pad, de query, het fragment en de headers. Het teken +, is alleen een spatie in het formaat application/x-www-form-urlencoded dat door HTML-formulieren en historisch door query strings wordt gebruikt. Overal elders blijft het een gewoon plusteken — en omdat het gemakkelijk te verwarren is, moet je het escapen in %2B zodra je een waarde codeert.
In de praktijk: om een formulierveld te vullen of het gedrag van een <form>, vink «Spatie als + » aan. Voor een redirect-URL, een canonical of een gedeelde link kies je altijd %20. De decoder behandelt + als spatie standaard en je kunt dit gedrag met één klik uitschakelen.
RFC 3986: unreserved, sub-delims en gen-delims
De RFC 3986 verdeelt de ASCII-tekens in drie categorieën. De niet-gereserveerde tekens — letters, cijfers, - _ . ~ — worden altijd ongewijzigd bewaard. De sub-scheidingstekens ! $ & ' ( ) * + , ; = en de generieke scheidingstekens : / ? # [ ] @ hebben een structurele betekenis: ze scheiden autoriteit, pad, query en fragment. De rest — spatie, aanhalingstekens, hoekjes, krulhaken en het procentteken — moet worden gecodeerd.
Dat zijn precies de categorieën die het tabblad «RFC 3986 & referentie» teken voor teken toont: klik op een tegel om de hexadecimale code, de categorie en de bereiken die het bewaren te zien. Dit is de snelste referentie om de vraag «moet ik dit teken escapen?» te beantwoorden.
Accenttekens, emoji's en UTF-8
Een URL vervoert alleen veilige ASCII-bytes, dus elk teken voorbij U+007F moet worden gecodeerd. In UTF-8 is « é » C3 A9 en wordt %C3%A9, « 日 » telt drie bytes en levert drie sequenties, een emoji er vier en telt uit als acht gecodeerde tekens. Als het resultaat je lang lijkt, is dat geen bug: het is de prijs van de compatibiliteit met alle protocollen. Let tot slot op het oorspronkelijke tekenset — een in Latin-1 gecodeerde string decoderen als UTF-8 geeft vreemde tekens, vandaar de vier opties in het tabblad «Decoderen».
Waarom encodeURIComponent niet altijd volstaat
encodeURIComponent codeert alles behalve A-Z a-z 0-9 - _ . ! ~ * ' ( ), wat volstaat voor een parameterwaarde maar een volledige URL breekt omdat het ook schuine streepjes, dubbele punten en ampersands ontscaped. encodeURI doet het omgekeerde: het bewaart de structuur van de URL maar laat spaties en accenten door, dus het faalt op ruwe tekst. Beide werkingen worden hier gedekt — en meer, want de bereiken «Querystring» en «Padsegment» vullen het gat ertussen.
Percent-encoding en Base64: twee verschillende tools
Percent-encoding vervangt byte voor byte en behoudt de leesbaarheid van de oorspronkelijke tekst, ten koste van een flinke uitbreiding. Base64 groepeert de bytes per drie en herschrijft ze in een alfabet van 64 tekens: compact maar totaal onleesbaar, en zonder URL-safe-variant niet bruikbaar in een URL. Het tabblad «Kruiscoderingen» toont beide in één blik, met als bonus de hexadecimale bytes, de HTML-entiteiten en de geëscape JSON-string — zodat je de juiste representatie kiest voordat je iets kopieert.
Veelgemaakte fouten: dubbel coderen en losse %
De meest voorkomende fout is om dezelfde string twee keer te escapen: een spatie wordt %20, daarna %2520, en de server krijgt letterlijk « %20 » terug. De tweede is om het procentteken zelf te vergeten, dat moet worden %25 — anders denkt de decoder dat het het begin van een sequentie is en crasht of knipt hij af. Tot slot: een + niet-geëscapede teken in een formularparameter staat gelijk aan een spatie die je niet had gevraagd. De decoder meldt onjuist gevormde sequenties en de knop «%-tekens corrigeren» herstelt het tweede geval zonder verlies.
Waar gecodeerde URL's zich verbergen
In de query strings van tracking UTM, in de redirect_uri en de toestanden van OAuth, in de webhooks waarvan de doel-URL geneste parameters bevat, in de callback-URL met handtekening, in serverlogs, in sitemaps en canonicals, in de <a href> aan clientzijde gegenereerd, in de JWT waarvan de payload in Base64URL staat, in de data: en de headers Location, en in elk HTML-formulier dat via GET wordt verstuurd. In een seconde kunnen coderen en decoderen voorkomt dat je voor één string een terminal opent.
Prestaties en beste praktijken
In de browser zijn coderen en decoderen lineair en kosten ze nauwelijks iets, zelfs bij enkele megabytes: elk teken wordt één keer verwerkt, zonder recursie en zonder allocatie per teken. De enige valkuilen zijn dubbel coderen — test altijd de round-trip voordat je iets opslaat — en URL's van enkele kilobytes, die door proxies vaak boven de 2 000 tekens worden afgekapt. Leg het gebruikte bereik vast naast de geproduceerde string: «component» en «volledige URL» geven niet hetzelfde resultaat voor dezelfde tekst.
Aanbevolen voor
Back-end- en front-endontwikkelaars (query strings, redirects, OAuth), integrators en technische redacteuren (UTM-links, canonical, tracking), systeembeheerders en DevOps (webhooks, getekende URL's, logs), testers en pentesters (parameterfuzzing, filterbypass), studenten (UTF-8, ASCII en RFC 3986 begrijpen) en iedereen die een online URL-encoder en -decoder zoekt, snel, compleet en vertrouwelijk — met als aanvulling de Base64-encoder en -decoder en de JSON-formatter.