👤 Pro — geen advertentiesPro
// JWT → header + payload

JWT-decoder

Plak een JSON Web Token om te zien wat er eigenlijk in zit — de header en payload, gedecodeerd en netjes opgemaakt.

Gratis — onbeperkt gebruik.

Wijs worden uit de claims die erin zitten

Eenmaal gedecodeerd, is de payload van een token vooral een handvol korte, gestandaardiseerde velden die claims heten. Degene die je voortdurend tegenkomt: iss noemt de issuer die het token gemaakt heeft, sub identificeert de gebruiker of het onderwerp waar het over gaat, aud noemt het publiek — de API waarvoor het bedoeld is — terwijl iat vastlegt wanneer het uitgegeven is en exp wanneer het ophoudt geldig te zijn. Al het andere daarin is op maat: rollen, e-mailadressen, feature flags, wat het uitgevende systeem ook heeft besloten erin te stoppen. De tijdclaims struikelen mensen omdat het gewone Unix-timestamps zijn, seconden sinds 1970 — een getal zoals 1784528768 in plaats van een leesbare datum — waardoor de hele levensduur van het token verstopt zit in twee onopvallende gehele getallen.

Een afgewezen token debuggen

Antwoordt een API met 401 en ben je zeker dat het token klopt, loop dan een kort lijstje af. Kopieerde je het uit een Authorization-header, haal dan eerst het woord Bearer en de spatie ervoor weg — met die eraan vast is het geen geldig JWT en decodeert het niet eens. Lees vervolgens exp en controleer of hij écht in de toekomst ligt: plak het getal in de Unix-timestamp-converter en je ziet de vervaldatum als een echte datum, wat vaak een token onthult dat al uren geleden gestorven is. Vergelijk daarna aud en iss met de API die je aanroept — een token gemunt voor de staging-omgeving wordt routinematig, en terecht, geweigerd door productie. En onthoud dat één minuut klokverschil tussen servers al genoeg is om een net uitgegeven token nog-niet-geldig te doen lijken.

Tokens die deze tool niet kan openen

Niet alles wat een API bewaakt, is een leesbaar JWT. Een token met vijf door punten gescheiden delen in plaats van drie is een JWE — echt versleuteld, niet enkel gecodeerd — en zonder de sleutel komt er niets leesbaars uit, hier noch ergens anders. En heel wat sessietokens zijn simpelweg ondoorzichtige willekeurige tekenreeksen die nooit JWT's zijn geweest; begint het niet met iets als eyJ, dan valt er vermoedelijk niets te decoderen. Voor de tokens die wél opengaan, helpt het om te onthouden waar je naar kijkt: drie blokken Base64URL-tekst aan elkaar geplakt met punten. De Base64-tool decodeert elk afzonderlijk blok op zichzelf, een leuke manier om met eigen ogen te zien dat de leesbare delen van een JWT nooit geheim zijn geweest.

Wat het decoderen van een JWT je wel en niet vertelt

De header en payload van een JWT zijn gewoon Base64URL-gecodeerde JSON — iedereen kan ze decoderen en lezen, zonder geheim nodig, en dat is precies wat deze tool doet. Wat hij niet kan, is de handtekening verifiëren: daarvoor is het geheim of de publieke sleutel van de uitgever nodig, en die plak je bewust niet in een willekeurige website.

Controleert dit of het token geldig is of nog niet verlopen?

Nee — dit decodeert alleen de leesbare delen. Het verifiëren van de handtekening en het controleren van de vervaldatum ("exp") gebeurt op de server die het token heeft uitgegeven, met een geheim dat deze tool nooit te zien krijgt.

Hoort een JWT zo leesbaar te zijn?

Ja — de header en payload zijn alleen gecodeerd, niet versleuteld. Zet nooit geheimen of gevoelige gegevens rechtstreeks in een JWT-payload; daar is de handtekening voor bedoeld (bewijzen dat er niet mee geknoeid is), niet om de inhoud te verbergen.

Wordt mijn token ergens naartoe verstuurd?

Nee — het decoderen gebeurt volledig in je browser met pure JavaScript. Er wordt niets geüpload.

Convertburda — universele conversies