JWT Decoder
Plak een JSON Web Token om de header en payload te lezen, te zien wanneer het verloopt en elke claim te begrijpen. Je token verlaat nooit je browser.
Draait in je browserGeen account nodigNiets wordt geüpload
Decoderen is niet verifiëren. Iedereen kan de header en payload van een JWT lezen, want die zijn alleen base64url-gecodeerd. Deze tool laat zien wat het token beweert; het bewijst niet dat het token echt is. Verifieer de handtekening altijd op je server.
Header
Payload
Claims uitgelegd
Handtekening verifiëren (optioneel, HS256/HS384/HS512)
Controleert een HMAC-handtekening met een secret dat je invoert, via de Web Crypto API van je browser. Het secret verlaat deze pagina nooit. RSA/ECDSA-tokens hebben de publieke sleutel van de uitgever nodig en worden hier niet geverifieerd.
Zo gebruik je de JWT Decoder
- Plak het token in het veld Gecodeerd token. Een voorafgaande
Beareruit een Authorization-header wordt genegeerd. - De header en payload worden direct gedecodeerd en als opgemaakte JSON getoond.
- Bekijk de tabel Claims uitgelegd:
exp,iatennbfworden omgezet naar datums met tijden als „verloopt over” / „verlopen sinds”. - Controleer de statusbalk op verloopproblemen en de waarschuwingen voor riskante instellingen zoals
alg: none. - Voer optioneel het shared secret in om een HS256-, HS384- of HS512-signature lokaal te verifiëren.
Wat zit er in een JWT?
Een JSON Web Token (RFC 7519) bestaat uit drie base64url-strings, gescheiden door punten: header.payload.signature. De header noemt het signeeralgoritme (alg) en het tokentype. De payload bevat de claims, zoals wie de gebruiker is en wanneer het token verloopt. De signature wordt over de eerste twee delen berekend met een secret of private key.
Decoderen is niet verifiëren
De header en payload zijn alleen gecodeerd, niet versleuteld, dus iedereen die het token heeft kan ze lezen. Zet daarom nooit wachtwoorden of secrets in een JWT-payload. Decoderen vertelt je wat een token beweert. Het verifiëren van de signature, normaal op je API-server met een library zoals jose of PyJWT, bewijst wie het heeft uitgegeven en dat het niet is aangepast. Een server moet ook exp, nbf, iss en aud controleren en onverwachte algoritmen weigeren.
Spiekbriefje geregistreerde claims
| Claim | Betekenis |
|---|---|
iss | Issuer: wie het token heeft aangemaakt en gesigneerd |
sub | Subject: meestal de gebruikers-ID |
aud | Audience: voor welke API het token bedoeld is |
exp | Verlooptijd, in seconden sinds de Unix-epoch |
nbf | Niet geldig vóór dit tijdstip |
iat | Tijdstip van uitgifte |
jti | Unieke token-ID, handig voor intrekkingslijsten |
Fouten als „token expired” debuggen
Weigert een API een token dat vers lijkt, vergelijk dan exp en nbf met de klok van de server. Een klein tijdsverschil tussen machines komt vaak voor, daarom staan de meeste libraries 30-60 seconden speling toe. Controleer ook of exp in seconden staat: een waarde in milliseconden is een veelgemaakte bug en legt de verlooptijd duizenden jaren in de toekomst.
Veelgestelde vragen
Is het veilig om hier een productie-JWT te plakken?
Verifieert deze tool de JWT-signature?
Waarom wordt mijn token als verlopen getoond?
exp-claim ligt in het verleden ten opzichte van de klok van je computer. Vraag een nieuw token aan of vernieuw het met je refresh token. Kloppen de tijden niet, controleer dan op tijdsverschil tussen klokken of een exp-waarde in milliseconden.Wat is het verschil tussen JWT, JWS en JWE?
Waarom is alg „none” gevaarlijk?
alg: none weigeren en alleen het specifieke algoritme accepteren dat ze verwachten.