Encoders & Utilities

JWT Decoder

Decodeer JWT-header en -payload veilig in de browser.

JWT token Paste a JWT — we will split it into header, payload, and signature.

Over deze tool

Een JSON Web Token (RFC 7519) bestaat uit drie Base64url-gecodeerde segmenten gescheiden door punten: header, payload en signature. JWT Decoder splitst het token, decodeert de eerste twee segmenten naar JSON, formatteert ze en berekent de tijdgerelateerde claims (iat, exp, nbf) als menselijk leesbare timestamps. Standaard geregistreerde claims (iss, sub, aud, jti) worden gelabeld met hun betekenis. Decodering draait volledig in uw browser — uw token verlaat nooit de pagina.

De header vertelt u het ondertekenings-algoritme (alg: HS256, RS256, ES256, etc.) en de optionele kid (key ID). De payload bevat de application-claims — gebruikers-ID, rollen, vervaldatum. De signature wordt getoond als een Base64-blob; we verifiëren deze opzettelijk niet op deze pagina omdat verifiëren het geheim van de uitgever of publieke sleutel vereist, wat nooit in een derde-partij-tool moet worden geplakt. Het token wordt alleen als data behandeld.

Wanneer gebruikt u deze tool

Een token van uw eigen dienst lezen. Inspecteer welke claims u werkelijk uitzendt — spot snel ontbrekende velden, verkeerde audiences of verrassende standaarden.
"401 Unauthorized"-antwoorden debuggen. Controleer vervaldatum, uitgever, audience en scope tegen wat de server verwacht.
Een derde-partij-integratie verifiëren. Wanneer een OAuth-provider u een ID-token overhandigt, decodeer de payload om te zien welke gebruikersclaims ze bundelen.
Algoritme-verwarring spotten. Als alg none is of onverwacht verschilt tussen tokens, is uw auth-bibliotheek waarschijnlijk misgeconfigureerd.

Waarom we signatures niet valideren

JWT-signature-verificatie vereist het geheim (voor HMAC-algoritmen) of de publieke sleutel van de uitgever (voor RSA/ECDSA). Een van die twee in een webtool plakken is een beveiligingsfout — het geheim zou elk uitgegeven token compromitteren; de publieke sleutel, hoewel minder gevoelig, kan nog steeds privé zijn. De decoder bevestigt structuur en onthult claims; voor echte verificatie gebruikt u de SDK die met uw auth-bibliotheek wordt geleverd (jsonwebtoken, pyjwt, jose) binnen uw eigen code.

Veelgestelde vragen

Is het veilig om mijn JWT hier te plakken?

Decodering vindt volledig in JavaScript in uw browser plaats — er wordt geen netwerkaanvraag gedaan, er gebeurt geen server-side logging. Dat gezegd hebbende, JWT's in productie moeten als credentials worden behandeld: plak geen langlevend token van een dienst die u niet beheert in welke derde-partij-tool dan ook, inclusief de onze. Voor dev/staging-tokens of vervallen tokens is decoderen hier prima.

Waarom wordt de signature getoond maar niet geverifieerd?

Omdat verificatie de ondertekensleutel vereist, en een ondertekensleutel in een webtool plakken zou een ernstige fout zijn. De signature wordt als Base64 weergegeven zodat u kunt zien dat hij bestaat en de juiste lengte heeft voor het algoritme, maar het werkelijk valideren tegen een HMAC-geheim (HS256) of een publieke sleutel (RS256/ES256) hoort binnen uw applicatie, niet in een browsertool.

Wat betekent "alg: none"?

Een onge-ondertekend JWT. De header zegt expliciet dat geen algoritme is toegepast, dus het signature-segment is leeg. alg: none bestaat in de spec maar zou nooit in productie mogen verschijnen — het is de hoofdoorzaak van de beroemde "JWT none-algorithm"-kwetsbaarheid waar een bibliotheek none als geldig accepteert. Als u het in een echt token van een echte dienst ziet, is dat een ernstige bug.

Wat is het verschil tussen exp, iat en nbf?

iat (issued-at) is wanneer het token werd aangemaakt. nbf (not-before) is het vroegste tijdstip waarop het token mag worden gebruikt — meestal gelijk aan iat maar kan in de toekomst liggen voor uitgestelde activering. exp (expiration) is wanneer het token niet meer geldig is. Alle drie zijn Unix-timestamps in seconden. Een goed gedragende verifier controleert nbf ≤ nu ≤ exp op elk verzoek.