JWT-encoder / -decoder

Wat betekent « JWT decoderen »?

Een JWT decoderen (« jwt decode », « decode jwt online ») betekenen de tekenreeks bij de dubbele punten splitsen en daarna elk Base64URL-segment decoderen om de oorspronkelijke JSON terug te vinden. Er is geen sleutel nodig: header en payload zijn alleen gecodeerd, niet versleuteld. Dat is precies de intentie achter « jwt payload decoder » of « decode jwt without verify » — zien wat er in de token zit, zonder te beweren dat die echt is.

Let goed op het verschil tussen beide handelingen. Lezen een JWT bewijst niets: iedereen kan een token met aantrekkelijke payload maken en die met zijn eigen geheim tekenen. Verifiëren de handtekening bewijst dat de inhoud niet door derden is gewijzigd. Een decoder die « admin: true » toont zonder handtekeningcontrole vertelt je een verhaal, geen feit.

De drie segmenten van een JWT

De tekenreeks splitst precies in drie door punten gescheiden delen: header.payload.signature. De header bevat minimaal alg en typ, soms kid om aan te geven welke sleutel is gebruikt. De payload bevat de claims, deze sleutel-waarde-paren waarvan het register door de IANA wordt bijgehouden. De handtekening dekt de eerste twee segmenten aan elkaar geplakt precies zoals ze geschreven zijn — elke wijziging van een spatie of teken laat de vergelijking falen.

Het hele punt is dat deze segmenten Base64URL zijn en geen Base64: het plusteken wordt een streepje, de schuine streep een underscore en het padding = vervalt. Een klassieke Base64-decoder faalt dus op een geldig JWT. De tabel « Base64URL versus klassiek Base64 » in het tabblad referentie toont precies deze vervangingen.

Een handtekening verifiëren: HS256, RS256, ES256

Voor een algoritme HMAC — HS256, HS384, HS512 — dient hetzelfde geheim om te tekenen én te verifiëren: de tool berekent HMAC(secret, base64url(header) + "." + base64url(payload)) en vergelijkt het resultaat met de meegeleverde handtekening. Dat is het meest voorkomende én gevaarlijkste geval: elke dienst die het geheim bezit kan een token uitgeven. Een geheim van minder dan 32 bytes, hergebruikt tussen omgevingen, is genoeg om de hele keten te compromitteren.

Voor de algoritmen asymmetrische — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — heb je voor verificatie alleen de openbare sleutel nodig, zodat je een door derden uitgegeven token controleert zonder het ondertekeningsgeheim ooit te delen. Plak de sleutel in PEM-formaat -----BEGIN PUBLIC KEY----- (SPKI); het ruwe resultaat van een OpenSSL-export is direct bruikbaar. Bij ES256 staat de handtekening in ruw r||s-formaat, precies zoals WebCrypto verwacht.

Tot slot moet je oppassen voor de alg confusion : als je dienst RS256 verwacht maar een token accepteert waarvan de header HS256 aangeeft, tekent een aanvaller met de openbare sleutel — die daarmee een HMAC-sleutel wordt — en slaagt de verificatie. Leg het verwachte algoritme serverzijdig vast en lees het nooit uit de token zelf.

exp, iat, nbf: de tijdstempels die valkuilen verbergen

Deze drie claims zijn Unix-seconden, zonder milliseconde en zonder tijdzone: iat « 1516239022 » betekent 2018-01-17T21:30:22Z. Twee fouten komen steeds terug: vergelijken met een datum in milliseconden (waarde tienduizend keer te groot) en een timestamp lokaal in plaats van in UTC interpreteren. Het tabblad « Vervaldatum » rekent in beide richtingen en toont de ISO 8601, de lokale datum en de resterende of verstreken tijd — zo herken je een « al verlopen » token direct tot op de seconde.

De levensduur verlengen verhoogt de beveiliging niet: een exp opgeschoven waarde wijzigt de getoonde waarde, niet de handtekening. Als je opnieuw moet uitgeven, teken je de token opnieuw met het geheim of de privésleutel — dat is precies de rol van het tabblad « Encoderen ».

Base64URL: waarom klassieke decoders falen

Base64URL (RFC 4648 §5) gebruikt het alfabet A-Z a-z 0-9 - _ en kent geen padding. Een payload van 20 tekens levert na het verwijderen van het = : dat is normaal, geen corruptie. De tekens - en _ zijn dubbelzinnig voor het menselijk oog, en dat verklaart de helft van de gemelde « kapotte tokens ». Onze decoder accepteert beide alfabetten, gemengde schrijfwijze, optionele padding en een prefix Bearer.

Beveiliging: wat een JWT niet doet

Een JWT biedt geen vertrouwelijkheid en geen intrekking. De payload is voor iedereen leesbaar: nooit een e-mail, een interne rol of persoonsgegevens die je niet in plaintext zou versturen. En een getekende token blijft geldig tot exp ook na uitloggen — er is een intrekkingslijst nodig, een jti serverzijdige bijhouding, of korte levensduur met refresh token. Een goede gewoonte: exp kort (10 tot 15 minuten), iat gecontroleerd, nbf afgestemd op iat, aud en iss bij ontvangst geverifieerd.

Aanbevolen voor

Back-end- en front-endontwikkelaars (OAuth 2.0, OpenID Connect, REST-API), integratiepartners en DevOps (identiteitsinfrastructuur, JWKS, sleutelrotatie), testers en pentesters (claims herschrijven, alg confusion, verloop), systeembeheerders (debuggen van een onverklaarbare 401), studenten (Base64URL en WebCrypto begrijpen) en iedereen die een JWT-decoder online snel, compleet en vertrouwelijk nodig heeft — aangevuld met deBase64 encoder/decoder, deURL encoder/decoder en de JSON-formatter.

JWT-decoder 100 % lokaal: je token verlaat nooit je computer

In tegenstelling tot klassieke JWT-decoders online wordt niets verstuurd: decoderen, handtekeningcontrole en coderen gebeuren volledig in je browser via WebCrypto, zonder externe bibliotheek en zonder netwerkverzoek. Zo kun je een echte sessietoken, een staging-sleutel of een interne servicetoken zonder risico inspecteren, ook offline of in een openbaar netwerk. Geschiedenis en laatste invoer worden lokaal (localStorage) bewaard en blijven op je apparaat.

De licentie Premium Volade voegt een optionele, versleutelde cloudsynchronisatie toe die onafhankelijk van de tool werkt — de rest blijft gratis en onbeperkt, zonder registratie.