Naar inhoud springen

JWT's decoderen en verifiëren

Decodeer de header en claims van een JSON Web Token, controleer de vervaldatum en verifieer de handtekening; je token verlaat je browser niet.

Wordt gedecodeerd en geverifieerd in dit tabblad – het token en de sleutels worden nergens naartoe gestuurd.

De header, claims en geldigheid verschijnen hier zodra je een token plakt.
Werkt in je browser · geen uploadZo werkt het

Zo gebruik je JWT-decoder

  1. 1

    Plak de token

    Plak de JWT uit een Authorization-header, een cookie of de opslag van je app; een “Bearer ” aan het begin wordt genegeerd.

  2. 2

    Lees de claims

    Bekijk de tabellen met header en payload, de leesbare tijden van exp, iat en nbf en de banner over de vervaltijd.

  3. 3

    Voeg de sleutel toe

    Vul de HMAC-sleutel in of plak de publieke sleutel als PEM, certificaat, JWK of JWKS.

  4. 4

    Verifieer de handtekening

    Klik op Handtekening verifiëren om te controleren of de token met die sleutel is ondertekend en niet is gewijzigd.

Limieten en Pro

Gratis, zonder account en zonder limiet op het aantal tokens; verificatie ondersteunt 13 algoritmen (HS, RS, PS en ES met 256, 384 en 512 bits, plus EdDSA).

Pro haalt de advertenties weg; decoderen en verifiëren werken bij elk abonnement hetzelfde. Pro bekijken

Over JWT-decoder

Een JSON Web Token bestaat uit drie Base64URL-strings die met punten aan elkaar zijn geplakt: een header met het ondertekeningsalgoritme, een payload met claims en een handtekening. Plak er een – met of zonder het voorvoegsel “Bearer ” – en de decoder toont de header en payload als leesbare tabel of als opgemaakte JSON, geeft de drie delen van de token een eigen kleur en legt standaardvelden als iss, sub, aud, kid en scope uit.

Tijdclaims worden voor je omgezet: exp, iat, nbf en auth_time verschijnen als datum in jouw tijdzone, in UTC en als relatieve tijd (“verloopt over 2 uur”, “3 dagen geleden verlopen”). Een banner laat in één oogopslag zien of de token verlopen is, nog niet geldig is of geen vervaltijd heeft, en waarschuwt als exp in milliseconden lijkt te staan in plaats van in seconden.

Decoderen bewijst niets over wie een token heeft uitgegeven. Daarom controleert de verificatie de handtekening met de ingebouwde WebCrypto van je browser. HS256, HS384 en HS512 hebben de gedeelde geheime sleutel nodig (platte tekst of Base64). RS-, PS- en ES-algoritmen met 256, 384 en 512 bits, plus EdDSA met Ed25519, hebben de publieke sleutel nodig. Die plak je als PEM-sleutel, RSA PUBLIC KEY-blok, X.509-certificaat, losse JWK of complete JWKS, waarbij de sleutel wordt gekozen op basis van de kid van de token.

De tool kan JWE-tokens (die met vijf delen) niet ontsleutelen en haalt geen JWKS-URL's op; open zelf de jwks_uri van de uitgever en plak de JSON.

Privacy

Tokens zijn bearer-inloggegevens en deze pagina behandelt ze ook zo: decoderen en handtekeningcontroles draaien in je browser met WebCrypto. De token, de geheime sleutel en de sleutels worden nooit naar een server gestuurd, gelogd of opgeslagen. Als je het tabblad sluit of herlaadt, is alles gewist.

Functies

Leesbare tijden

exp, iat en nbf in jouw tijdzone, in UTC en als “over 2 uur” of “3 dagen geleden”.

Echte handtekeningcontrole

HMAC, RSA, RSA-PSS, ECDSA en Ed25519 geverifieerd met WebCrypto, aan de hand van je sleutel of JWKS.

Token blijft lokaal

Er wordt niets geüpload, dus je kunt productietokens veilig inspecteren.

JWT-decoder: veelgestelde vragen

Is het veilig om een productietoken hier te plakken?
De token wordt gedecodeerd en geverifieerd door JavaScript in je eigen tabblad en er wordt geen verzoek met de token verstuurd, wat je kunt nagaan in het netwerkpaneel van je browser. Toch werkt een geldige token als een wachtwoord tot hij verloopt. Plak live tokens dus niet op sites die je niet vertrouwt en gebruik verlopen of testtokens als je schermafbeeldingen deelt.
Waarom bewijst een gedecodeerde token niets?
Iedereen kan een header en payload maken en met Base64URL coderen; decoderen draait dat alleen terug. Alleen de handtekening koppelt de token aan de uitgever. Verifieer die met de publieke sleutel van de uitgever of de gedeelde geheime sleutel voordat je een claim vertrouwt, en controleer of alg is wat je server verwacht, want het accepteren van “none” of een verwisseld algoritme is een klassieke kwetsbaarheid.
Waar vind ik de publieke sleutel om een RS256- of ES256-token te verifiëren?
Identity providers publiceren hun sleutels als JWK Set. Zoek de /.well-known/openid-configuration van de uitgever op, open de jwks_uri die daarin staat en plak die JSON hier; de sleutel waarvan de kid overeenkomt met de tokenheader wordt gebruikt. Je kunt ook een PEM-publieke sleutel of het X.509-certificaat van de uitgever plakken.
Wat betekenen exp, iat en nbf?
Het zijn NumericDate-claims, geteld in seconden sinds 1 januari 1970 UTC. exp is het moment waarop de token ongeldig wordt, iat het moment van uitgifte en nbf het vroegste moment waarop de token mag worden geaccepteerd. Servers staan meestal een minuut of twee afwijking van de klok toe. De decoder toont elk als lokale datum, UTC-tijdstempel en relatieve tijd.
Waarom mislukt de verificatie met de juiste HMAC-sleutel?
Veelvoorkomende oorzaken zijn spaties die met de sleutel zijn meegekopieerd, een sleutel die bij het ondertekenen Base64-gecodeerd was, of een token die is opnieuw gecodeerd door een tool die de bytes van de header of payload heeft gewijzigd. Probeer de schakelaar “Geheim is Base64-gecodeerd”. Elke wijziging in de eerste twee delen, zelfs een andere volgorde van JSON-sleutels, maakt de handtekening ongeldig.