JWT Decoder

Een JSON Web Token ziet eruit als een onleesbare brij tekens, maar het zijn in werkelijkheid gewoon drie met punten aan elkaar geplakte, Base64URL-gecodeerde delen: een header, een payload en een handtekening. De header en payload decoderen is geen vorm van versleuteling — iedereen die het token in handen krijgt, kan de claims erin gewoon lezen. Precies daarom hoort gevoelige data nooit in een JWT-payload thuis. Het probleem is dat de tokens die mensen willen inspecteren zelden wegwerp-testdata zijn. Vaak is het een live sessietoken van een productieapp, een API-toegangstoken, of een inlogcookie die net uit de devtools van de browser is geplukt tijdens het debuggen — een echte credential die, in verkeerde handen, echte toegang geeft. Zo'n token op een willekeurige website plakken betekent dat je jouw sessie overhandigt aan een server waar je niets van weet.

Deze tool doet dat nooit. De header en payload worden gedecodeerd met gewone JavaScript die in je browser draait, direct op het moment dat je een token plakt — gesplitst op de punten, Base64URL-gedecodeerd, geparseerd als JSON — en niets daarvan wordt ergens naartoe verzonden. Handtekeningverificatie werkt op dezelfde manier, met de Web Crypto API (`SubtleCrypto`) die in elke moderne browser is ingebouwd: HMAC-algoritmen (HS256, HS384, HS512) worden geverifieerd tegen een secret dat je zelf intypt, en RSA-algoritmen (RS256, RS384, RS512) tegen een publieke sleutel die je in PEM-formaat plakt. Zowel het cryptografische secret als de verificatie zelf blijven lokaal in het tabblad; ververs de pagina en alles — token, secret, sleutel — is verdwenen.

Plak een token en de header en payload worden overzichtelijk opgemaakt weergegeven, samen met een leesbare uitlezing van de standaard `exp`-, `iat`- en `nbf`-claims, omgezet naar een begrijpelijke datum, met een duidelijk "Verlopen"-label als het `exp` van het token al is verstreken — handig om te bevestigen dat een bugmelding als "ik werd uitgelogd" gewoon een verlopen token blijkt te zijn. Als het algoritme HS256/384/512 of RS256/384/512 is, voer dan het bijbehorende secret of de publieke sleutel in om te controleren of de handtekening echt is of geknoeid is. Algoritmen buiten die set (zoals ES256 of het niet-ondertekende `none`) worden nog steeds gewoon gedecodeerd, maar verificatie wordt dan niet aangeboden in plaats van een nagemaakt resultaat te tonen. Voor lokale ontwikkeling kun je met de bewerkbare header- en payloadvelden een claim aanpassen — bijvoorbeeld een gebruikers-ID of een rol wijzigen — en het token opnieuw ondertekenen met hetzelfde HS256-secret dat je testserver gebruikt, een gangbare manier om autorisatielogica te testen zonder een volledige inlogflow op te zetten.

Omdat de payload van een JWT, eenmaal gedecodeerd, gewone leesbare JSON is, sluit deze tool natuurlijk aan op de JSON-formatter en -validator als je een diep geneste claim wat grondiger wilt bekijken. Nog één beveiligingstip die het herhalen waard is: omdat decoderen geen enkel secret vereist, behandel elk token als gevoelig zodra je klaar bent met inspecteren, en vervang credentials die eigenlijk maar kortstondig hoorden te zijn als je niet zeker weet waar ze al geplakt zijn geweest voordat ze hier terechtkwamen.