Décodeur de JWT
Décodez n'importe quel JSON Web Token pour inspecter son en-tête, son payload et ses claims sous une forme lisible — et, si vous le souhaitez, vérifiez une signature HMAC (HS256/384/512). Tout reste dans votre navigateur.
Comment utiliser Décodeur de JWT
- 1
Collez votre token
Collez un JSON Web Token encodé dans le champ de saisie. Le décodeur le divise automatiquement en en-tête, payload et signature.
- 2
Lisez les claims
Inspectez l'en-tête et le payload décodés sous forme de JSON formaté, et examinez les claims enregistrés tels que l'expiration et la date d'émission, affichés sous forme de dates lisibles.
- 3
Vérifiez la signature
Pour les tokens HMAC, saisissez le secret de signature afin de confirmer que la signature est valide et que le token n'a pas été altéré.
- 4
Copiez ce dont vous avez besoin
Copiez le JSON formaté de l'en-tête ou du payload dans votre presse-papiers pour l'utiliser dans vos tests, votre documentation ou votre débogage.
Comprendre les JSON Web Tokens : anatomie, claims et pièges
Trois parties séparées par des points
Un JSON Web Token est une longue chaîne unique contenant deux points qui la divisent en trois segments : l'en-tête, le payload et la signature. Chacun des deux premiers segments est un petit objet JSON encodé en Base64URL — une variante du Base64 compatible avec les URL qui remplace quelques caractères et supprime le remplissage, afin que le token circule proprement dans les en-têtes et les chaînes de requête. Le troisième segment est la signature, calculée à partir des deux premiers.
Collez un token et le décodeur le sépare au niveau des points, puis décode en Base64URL les deux premières parties pour les ramener à du JSON lisible. Vous voyez l'en-tête et le payload exactement tels que l'émetteur les a écrits. La raison pour laquelle cela est possible est au cœur de tout ce qui suit : ces segments sont seulement encodés, pas chiffrés.
L'en-tête : algorithme et type
L'en-tête est la plus petite partie. Il déclare généralement le type — JWT — et, surtout, l'algorithme de signature dans son champ alg. Les valeurs courantes sont HS256, qui utilise un HMAC avec un secret partagé, et RS256 ou ES256, qui reposent sur des paires de clés asymétriques où une clé privée signe et une clé publique vérifie. L'algorithme indique au vérificateur comment la signature a été produite, et donc comment la contrôler.
Le champ alg est aussi un enjeu de sécurité. Un token déclarant un algorithme none, ou un attaquant faisant passer un token d'un algorithme asymétrique à un algorithme symétrique pour tromper un vérificateur naïf et lui faire utiliser la clé publique comme secret HMAC, sont des attaques classiques. Un vérificateur correct fixe l'algorithme attendu plutôt que de faire aveuglément confiance à ce que dit l'en-tête.
Le payload et ses claims enregistrés
Le payload transporte les claims — les affirmations que fait le token. Un ensemble de noms de claims enregistrés est normalisé afin que des systèmes différents s'accordent sur leur signification. Le claim d'émetteur (iss) indique qui a créé le token, le claim de sujet (sub) identifie de qui ou de quoi il s'agit (souvent un identifiant d'utilisateur), et le claim d'audience (aud) désigne le destinataire prévu. À côté de ceux-ci, on trouve généralement des claims applicatifs personnalisés comme un rôle ou un locataire.
Ce décodeur fait ressortir les claims enregistrés sous une forme étiquetée et lisible, pour que vous n'ayez pas à reconnaître par cœur ces noms abrégés et obscurs. Voir l'émetteur, le sujet et l'audience écrits en toutes lettres suffit souvent lorsque vous examinez un token au cours d'un débogage pour confirmer qu'il s'agit bien du bon, destiné au bon service.
Les claims temporels : exp, iat et nbf
Trois claims régissent la durée de vie d'un token, et tous sont des timestamps Unix mesurés en secondes — pas en millisecondes, ce qui constitue un fréquent bug d'un facteur mille pour les développeurs JavaScript habitués au temps en millisecondes. Le claim d'expiration (exp) est l'instant après lequel le token doit être rejeté, le claim de date d'émission (iat) consigne le moment de sa création, et le claim « pas valide avant » (nbf) marque le premier instant où il devient valide.
Le décodeur convertit ces valeurs en dates lisibles et vous indique si le token est actuellement actif, pas encore valide ou expiré selon l'horloge de votre appareil. Ce dernier détail compte : si l'horloge de votre ordinateur est fausse, le verdict actif-ou-expiré peut être trompeur, et en production, un décalage d'horloge entre serveurs est une cause fréquente de rejet d'un token tout juste émis comme « pas encore valide ».
Décoder n'est pas vérifier
C'est la chose la plus importante à intégrer. N'importe qui peut décoder un JWT — ce n'est que du Base64URL — si bien que lire les claims vous dit ce que le token affirme, pas si le token est authentique. La confiance ne vient que du contrôle de la signature par rapport à la clé, qui prouve que le token a été émis par une partie détenant le secret ou la clé privée et qu'il n'a pas été modifié depuis.
Pour les tokens HMAC (HS256, HS384, HS512), cet outil peut recalculer la signature à partir de l'en-tête, du payload et du secret que vous fournissez, puis la comparer à la signature du token, confirmant ainsi l'authenticité pour ce secret. Les algorithmes asymétriques tels que RS256 et ES256 nécessitent la clé publique de l'émetteur : ils sont décodés mais non vérifiés ici. Surtout, les véritables décisions d'autorisation doivent vérifier la signature côté serveur ; ne faites jamais confiance aux claims d'un token sur la seule base d'un décodage dans du code client.
Le payload n'est pas secret
Parce que le payload est seulement encodé, chaque claim qu'il contient est parfaitement visible pour quiconque obtient le token — le navigateur, n'importe quel proxy, l'utilisateur lui-même. Un JWT est un excellent endroit pour des données d'identité et d'autorisation non sensibles, et un très mauvais endroit pour quoi que ce soit de confidentiel. Ne placez jamais un mot de passe, un secret d'API, un numéro de carte bancaire ou des données personnelles privées dans le payload en pensant que l'encodage les protège. Ce n'est pas le cas.
La signature protège l'intégrité, pas la confidentialité : elle empêche l'altération, mais ne fait rien pour masquer le contenu. Si vous avez réellement besoin d'un token chiffré dont le payload ne peut pas être lu, il s'agit d'une construction différente et plus lourde (JWE) — un JWT standard est signé, pas chiffré. Gardez les secrets sur le serveur et référencez-les dans le token par un identifiant opaque.
Déboguer les tokens en toute sécurité
Au quotidien, le décodeur excelle pour déboguer les flux d'authentification : confirmer que le bon utilisateur figure dans le claim de sujet, vérifier que l'audience correspond au service qui rejette la requête, contrôler la présence des portées ou des rôles, et lire l'expiration pour voir si un 401 n'est qu'un simple token périmé. Copier l'en-tête ou le payload formaté dans un rapport de bug ou un jeu de test se fait en un clic.
Tout se passe localement dans votre navigateur — le token et tout secret que vous saisissez ne sont jamais envoyés, enregistrés ni stockés — il est donc sûr d'inspecter de vrais tokens de production. Cela dit, traitez les tokens comme les identifiants qu'ils sont : un token valide et non expiré est une clé active vers un compte, alors évitez de le coller dans des outils non fiables, et préférez des tokens expirés ou de test lorsque vous partagez des exemples.
Questions fréquentes
Qu'est-ce qu'un JSON Web Token (JWT) ?
Décoder un JWT révèle-t-il le mot de passe ou le secret ?
Comment fonctionne la vérification de la signature ici ?
Que signifient les claims exp et iat ?
Mon token est-il envoyé à un serveur ?
Outils similaires
Continuez avec ces outils pratiques