Décodeur JWT
Collez un token JWT pour voir le header, le payload et la signature, savoir s'il est encore valide et contrôler ses rôles et scopes. Le décodage se fait pendant que vous collez.
Le token, le secret et la clé publique restent dans votre navigateur. Rien n'est envoyé à un serveur, le nôtre compris, et tout disparaît quand vous fermez la page.
Pas encore de token
Collez un JWT dans le champ. Le statut, les dates et les claims s'affichent ici tout de suite.
Besoin d'un token avec d'autres claims, comme un admin et un utilisateur simple ?
Comment utiliser le Décodeur JWT ?
Collez le token
Copiez-le depuis les DevTools, Postman ou un log et collez-le. Bearer, guillemets et retours à la ligne sont retirés tout seuls.
Regardez le statut
Le statut indique si le token a expiré, quand il expire et à quelle heure, dans votre fuseau et en UTC.
Vérifiez la signature
Saisissez le secret ou la clé publique pour savoir si le token est authentique et intact.
Copiez ce qu'il vous faut
Copiez le token nettoyé, le header, le payload ou la valeur d'un claim en un clic.
Qu'est-ce qu'un JWT ?
Un JWT (JSON Web Token, RFC 7519) est un format de token qui sert à transmettre des informations entre systèmes, surtout pour la connexion et l'autorisation d'API. Le serveur d'authentification émet le token après la connexion, l'application l'envoie à chaque requête, et l'API lit ses claims pour savoir qui est l'utilisateur et ce qu'il peut faire.
Les trois parties d'un JWT
Un JWT comporte trois blocs en base64url séparés par des points :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGVzIjpbInVzZXIiXX0.3mG4X8mY2bJqS0mY7fUv0M1wS6Qy0p2WmH0x0J3bQKc- Header. Le header indique quel algorithme a signé le token (alg) et parfois quelle clé a été utilisée (kid).
- Payload. Le payload contient les claims : qui est l'utilisateur, quand le token expire, pour quelle API il est valable et quelles permissions il accorde.
- Signature. La signature est calculée sur le header et le payload. Si un seul caractère change, elle ne correspond plus.
Pourquoi on peut lire le payload sans mot de passe
Le header et le payload sont seulement encodés en base64url, une variante de Base64 qui remplace + et / par - et _ et supprime le = final. Encoder n'est pas chiffrer : toute personne qui a le token peut lire son contenu, et c'est exactement ce que fait cet outil. C'est pourquoi un mot de passe, un numéro de carte ou une donnée sensible n'ont rien à faire dans le payload d'un JWT.
Claims enregistrés et claims personnalisés
La RFC 7519 définit sept claims enregistrés : iss, sub, aud, exp, nbf, iat et jti. Ils ont des noms courts et un sens fixe, et les bibliothèques JWT vérifient exp, nbf et aud automatiquement. Tout le reste est un claim personnalisé, créé par l'application ou le fournisseur d'identité, comme roles, scope, email ou realm_access dans Keycloak. Dans le tableau des claims, chaque claim connu est accompagné d'une courte explication.
Décoder n'est pas valider
Lire le payload ne prouve rien sur le token. N'importe qui peut fabriquer un JWT avec un sub d'admin et un exp dans dix ans. L'authenticité vient de la signature, et c'est au backend de la vérifier, toujours avec l'algorithme fixé dans sa configuration plutôt qu'avec celui annoncé par le header. Utilisez la vérification de cette page pour déboguer, jamais pour remplacer la validation côté serveur.
Le risque de alg none
La valeur "none" dans alg désigne un token sans signature. Certaines anciennes bibliothèques acceptaient ces tokens quand le header le demandait : il suffisait à un attaquant de changer alg et de supprimer la signature pour se faire passer pour n'importe quel utilisateur. Quand cet outil trouve alg none, il affiche une alerte. Si votre API accepte un tel token, traitez-le comme une faille de sécurité.
JWS et JWE : signé ou chiffré
Presque tous les JWT qu'on croise sont des JWS : signés, en trois parties, avec un payload lisible. Le JWE est la version chiffrée, en cinq parties, et seul le détenteur de la clé de déchiffrement peut le lire. Si vous collez un JWE ici, l'outil vous le signale et n'affiche que le header, qui reste lisible.
Où trouver le token à coller ici
- Dans le header Authorization: Bearer d'une requête, dans l'onglet Network des DevTools ou dans Postman et Insomnia
- Dans un cookie de session, dans l'onglet Application des DevTools (le cookie peut être HttpOnly et invisible pour JavaScript)
- Dans la réponse de l'endpoint de token du fournisseur, dans les champs access_token et id_token
- Dans les logs de l'API gateway et de l'application, souvent coupé sur plusieurs lignes
Problèmes courants en déboguant connexion et permissions
La connexion échoue en 401 au bout d'un moment
Le statut montre si l'exp est dépassé et depuis combien de temps. Si le token expire en quelques minutes, vérifiez que le front utilise le refresh token pour en obtenir un nouveau.
Un utilisateur connecté reçoit un 403
Regardez le bloc des rôles et scopes. Si le rôle attendu n'y est pas, le problème vient de la configuration du fournisseur ou du type de token envoyé (envoyer l'ID token au lieu de l'access token est une erreur fréquente).
Token refusé juste après son émission
exp, iat et nbf comptent des secondes en UTC et ne dépendent pas du fuseau horaire. Quand un token tout juste émis est refusé, la cause est souvent un décalage d'horloge entre serveurs. Les dates s'affichent dans votre heure et en UTC pour faciliter la comparaison avec les logs.
Token valide refusé par une autre API
Vérifiez l'aud. Chaque API ne doit accepter que les tokens émis pour elle, donc le token d'une API ne fonctionne pas pour une autre.
Questions Fréquentes sur le Décodeur JWT
Ce qui revient souvent quand on lit et débogue des tokens JWT.