Décodeur JWT

Comment décoder un JWT

1. Collez le jeton dans Jeton. Une ligne Authorization: Bearer eyJ… entière fonctionne, tout comme des guillemets autour ou un jeton coupé sur plusieurs lignes.
2. Lisez le résultat. Les trois parties s’affichent dans des couleurs différentes, l’en-tête et le payload sont formatés, et Claims liste chaque claim avec sa signification. Les dates comme exp et iat apparaissent en heure locale, en UTC et en temps relatif du type « expire dans 1 heure ».
3. Pour vérifier la signature, collez le secret partagé ou la clé publique sous Vérifier la signature. Le libellé du champ suit l’alg du jeton : Secret pour HS256/384/512, Clé publique pour tout le reste.
4. Lisez les avertissements. L’outil signale alg: none, les jetons expirés, un nbf dans le futur, un exp manquant, des dates écrites en millisecondes, et les en-têtes qui pointent vers des clés distantes (jku, x5u) ou embarquent leur propre clé (jwk).

Vous pouvez aussi ouvrir un jeton directement avec un lien comme /jwt-decoder/#token=eyJ…. La partie après # est un fragment d’URL, et les navigateurs n’envoient jamais les fragments au serveur.

Ce que contient un jeton

Un JWT signé (un JWS en forme compacte) se compose de trois chaînes Base64URL reliées par des points : header.payload.signature. Voici un vrai jeton HS256, émis le 1er janvier 2026 et valide une heure :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyLTQyIiwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3NjcyMjkyMDB9.U3Gb12hN5Fnpi1rJ7nrkUzIEidkg-hPnbgiIpTah3R4

La première partie se décode en l’en-tête {"alg":"HS256","typ":"JWT"}. La deuxième est le payload :

{"iss":"https://auth.example.com","sub":"user-42","aud":"api.example.com","iat":1767225600,"exp":1767229200}

La troisième partie est un HMAC-SHA256 de 32 octets calculé sur les deux premières : modifier un seul caractère de l’en-tête ou du payload la casse. Presque tous les JWT commencent par eyJ, le Base64 de {". Les parties utilisent l’alphabet URL-safe (- et _) sans remplissage = ; comment les JWT utilisent Base64URL décode un jeton à la main, étape par étape.

JWS ou JWE : jetons signés ou chiffrés

La plupart des JWT sont des JWS : signés, lisibles par tous. Un JWE est chiffré et compte cinq parties au lieu de trois : header.encrypted_key.iv.ciphertext.tag. Son en-tête reste lisible et nomme l’algorithme de gestion de clé (alg, par exemple RSA-OAEP-256 ou dir) et l’algorithme de chiffrement du contenu (enc, par exemple A256GCM).

Collez un JWE ici et l’outil décode cet en-tête, affiche alg, enc et kid, et marque le payload comme chiffré. Le déchiffrer exige la clé privée du destinataire ou la clé partagée, et cet outil ne déchiffre pas les JWE. Si vous avez besoin d’un jeton dont les utilisateurs ne peuvent pas lire le payload, le JWE est le bon format ; mettre des secrets dans le payload d’un JWS revient à les mettre en clair, comme l’explique Base64 n’est pas du chiffrement.

Référence des claims JWT

Les sept premières lignes sont les claims enregistrés de la RFC 7519 ; les autres sont courants dans les jetons OpenID Connect et OAuth. Chaque valeur de date est une NumericDate : un nombre entier de secondes écoulées depuis le 1er janvier 1970 UTC, jamais de millisecondes.

L’en-tête a ses propres paramètres : alg (l’algorithme de signature), typ (généralement JWT, ou at+jwt pour les access tokens OAuth), kid (la clé qui l’a signé) et cty (vaut JWT quand un jeton est imbriqué dans un autre).

Vérifier la signature : quelle clé coller

Seule la vérification de la signature indique d’où vient un jeton, et la clé nécessaire dépend de la famille d’algorithmes indiquée dans l’en-tête.

Pour les jetons d’un fournisseur d’identité, les clés publiques se trouvent à l’adresse jwks_uri indiquée dans https://<issuer>/.well-known/openid-configuration. Cette page ne peut pas récupérer cette URL, car elle ne peut pas se connecter à d’autres serveurs : ouvrez-la dans un nouvel onglet et collez le JSON. Avec un JWKS, la clé est choisie d’après le kid ; si le jeton n’a pas de kid, toutes les clés compatibles sont essayées.

Les signatures ECDSA au format DER (en général 70 à 72 octets pour ES256 au lieu de 64) sont détectées, converties et signalées, car JWS exige r‖s brut et beaucoup de bibliothèques rejettent le DER. Une clé privée collée fonctionne aussi (la partie publique en est déduite), même si la vérification n’en a jamais besoin. ES256K et Ed448 ne sont pas pris en charge, car WebCrypto ne les propose pas.

Si un jeton HS256 échoue avec un secret dont vous êtes sûr, le secret est souvent encodé en Base64 quelque part dans votre configuration et le serveur le décode avant usage. Passez Le secret est sur Base64 et réessayez.

Pourquoi décoder un jeton ici est sûr

Un JWT dans un en-tête Authorization est un identifiant fonctionnel jusqu’à son expiration. Si vous collez un jeton de production actif dans une page web qui l’envoie à un serveur, l’exploitant de ce serveur peut le rejouer contre votre API, et de l’extérieur, vous ne pouvez généralement pas savoir si une page le fait.

Sur cette page, le décodage et la vérification de signature WebCrypto s’exécutent tous deux dans votre navigateur. La page applique aussi une Content Security Policy dont la directive connect-src n’autorise que /cdn-cgi/rum, où Cloudflare Web Analytics compte les pages vues : le navigateur bloque donc toute autre requête fetch, XHR, WebSocket ou beacon que la page pourrait tenter. Vous pouvez le vérifier vous-même : ouvrez les outils de développement sur l’onglet Réseau et collez un jeton, ou coupez le Wi-Fi une fois la page chargée et continuez à décoder.

Malgré cela, préférez des jetons de test ou sur le point d’expirer, et si un jeton de production a été collé à un endroit que vous ne contrôlez pas, révoquez la session.

Jetons expirés, nbf et décalage d’horloge

exp et nbf sont comparés à l’horloge du vérificateur, et les horloges dérivent. Un jeton émis par un serveur dont l’horloge avance de 30 secondes peut arriver avec iat et nbf dans le futur et être refusé comme « pas encore valide ». Les bibliothèques JWT acceptent donc une petite tolérance : leeway dans PyJWT, clockTolerance dans jsonwebtoken et jose.

Ce décodeur compare ces dates à l’horloge de votre appareil et décrit le résultat en toutes lettres : « a expiré il y a 2 jours » pour exp, « pas encore valide » avec le temps restant pour nbf, ou un avertissement indiquant que iat est dans le futur, ce qui met en cause l’horloge de l’émetteur. Une valeur comme 1767229200000 est signalée comme des millisecondes ; lue en secondes, elle tombe des dizaines de milliers d’années dans le futur, un bug courant quand le code utilise Date.now() au lieu de Math.floor(Date.now() / 1000).

Pour lire les claims dans le code sans vérifier la signature, la bibliothèque standard de Python suffit :

import base64, json

def b64url_decode(part):
    return base64.urlsafe_b64decode(part + "=" * (-len(part) % 4))

header_b64, payload_b64, signature_b64 = token.split(".")
print(json.loads(b64url_decode(payload_b64)))

En Node.js, JSON.parse(Buffer.from(payload_b64, "base64url").toString("utf8")) fait la même chose. Pour les décisions d’autorisation, utilisez une bibliothèque qui vérifie la signature et fixe les algorithmes acceptés. Vous trouverez d’autres extraits sur les pages Python et Node.js.

Pour construire ou resigner un jeton de test, utilisez l’encodeur JWT. Un segment isolé peut être décodé seul avec le décodeur Base64URL.

FAQ