JWT-decoder – gratis online

JWT-decoder om token-headers, payloads, claims en vervaltijd te bekijken

Als een inlogflow een 401 teruggeeft, een token te vroeg lijkt te verlopen of een controle op rol mislukt, is de eerste debugstap meestal: wat zit er eigenlijk in dit token? Deze JWT-decoder splitst het token in header en payload, decodeert de Base64-gecodeerde JSON en toont die met leesbare tijdstempels — volledig in de browser. Er wordt nooit een token verzonden; het decoderen gebeurt lokaal.

De decoder toont de exp-claim omgerekend naar je eigen tijdzone met een badge geldig/verlopen, de iat-tijd (uitgegeven op) en alle eigen claims. Hij verifieert de handtekening niet — dat vereist het secret of de publieke sleutel — maar geeft je wel de volledige gedecodeerde inhoud, zodat je kunt zien wat het token bevat voordat je uitzoekt waarom het niet wordt geaccepteerd.

Voor wie

• Frontend-ontwikkelaars — debuggen inloglussen, verlopen sessies en ontbrekende rol/rechten-claims zonder tokens in willekeurige online tools te plakken.
• Backend- en API-ontwikkelaars — controleren de tokenstructuur bij het testen van OAuth, OpenID Connect en eigen JWT-integraties.
• QA- en supportengineers — lezen de claims om te bepalen of een 401 of 403 een tokenprobleem is of een fout in de autorisatielogica.
• DevOps- en securityteams — inspecteren payloads tijdens incidentafhandeling en het oplossen van integratieproblemen.

Zo gebruik je het goed

1. Kopieer de volledige JWT uit de devtools van je browser (Application → Local Storage of Cookies), een Authorization-header of een curl-respons.
2. Plak hem in het invoerveld. De decoder splitst meteen de drie door punten gescheiden segmenten en decodeert de header en payload.
3. Vergelijk de exp-tijdstempel met de huidige tijd. De tool toont een badge geldig/verlopen — controleer ook de serverklok, want een afwijkende klok kan een vals verlopen token veroorzaken.
4. Lees de claims. Let op sub (gebruiker), aud (ontvanger), iss (uitgever), scope, roles en alle eigen claims die je applicatie verwacht.

Praktische tips

• Plak nooit productietokens in een tool die data naar een server stuurt. Deze decoder draait lokaal, maar toets de werkwijze toch aan het securitybeleid van je team.
• Vergelijk exp en iat met zowel de tijdzone van de gebruiker als de serverklok — een afwijking van vijf minuten kan stille fouten veroorzaken.
• Onthoud dat decoderen geen verificatie is. Een token dat met succes decodeert, kan nog steeds gemanipuleerd zijn als de handtekening niet met het juiste secret of de juiste sleutel wordt gecontroleerd.
• Controleer het veld alg in de header. Staat daar none, dan is het token niet ondertekend en mag je het niet vertrouwen.

Veelvoorkomende toepassingen

• OAuth- en OpenID Connect-inlogflows debuggen wanneer tokens niet worden geaccepteerd
• Rol-, scope-, tenant- en rechten-claims lezen tijdens het testen van API-integraties
• Checken of een token echt verlopen is voordat je de backend de schuld geeft
• Authenticatiebugs aan collega's uitleggen met leesbare header- en payload-uitvoer
• De tokenstructuur verifiëren tijdens incidentafhandeling — is het token kapot, verlopen of mist het claims?

Privacy en verwerking in de browser

Deze JWT-decoder draait volledig in je browser. Tokens die je plakt, worden nooit verzonden, opgeslagen of gelogd. Toch bevatten JWT-tokens vaak persoonsgegevens (e-mail, gebruikers-ID, naam) en kunnen ze toegang geven tot productiesystemen — volg het securitybeleid van je team wanneer je ze in welke tool dan ook gebruikt.

Gerelateerde zoekopdrachten en tools

Wie deze JWT-decoder gebruikt, heeft vaak ook de JSON-formatter nodig (gedecodeerde payloads netjes opmaken voor nadere inspectie), de Base64-encoder (handmatig Base64URL-segmenten coderen of decoderen) en de URL-encoder (parameters veilig coderen voor OAuth-redirect-URI's). Alle drie draaien in de browser.