Décodeur JWT
Lisez les claims d’un jeton, et prouvez sa signature · tourne dans cet onglet, n’est jamais envoyé nulle part
Jeton
Signature
Un JWT est encodé, pas chiffré — quiconque détient ce jeton peut lire tout ce qui précède sans aucune clé. Seule une vérification de signature vous dit qu’il est authentique et intact.
Claims
Collez un jeton dans le panneau Jeton et ses claims apparaîtront ici, en toutes lettres.
En-tête
Charge utile
Comment fonctionne le Décodeur JWT
Un décodeur JWT qui sépare un jeton en ses trois parties, décode l’en-tête et la charge utile, et liste chaque claim en toutes lettres — expiration, « pas avant » et date d’émission affichées comme de vraies dates plutôt qu’en secondes depuis 1970. Il vérifie aussi la signature : collez le secret partagé pour un algorithme HS ou une clé publique pour RS, PS ou ES, et le contrôle s’exécute via la WebCrypto de votre propre navigateur. Ni le jeton ni la clé ne sont jamais envoyés, et la clé n’est même pas enregistrée dans ce navigateur.
Collez un jeton — avec ou sans son préfixe Bearer — et il se sépare en ses trois parties, colorées pour que vous voyiez où chacune s’arrête. L’en-tête et la charge utile sont décodés en JSON, et les claims sont repris en toutes lettres, avec exp, nbf et iat affichés comme de vraies dates ainsi qu’en durée écoulée ou restante.
Décoder un JWT n’est pas le vérifier. Les deux premières parties sont en base64url, pas chiffrées : quiconque détient le jeton peut les lire, et c’est pourquoi un jeton n’est jamais un endroit où mettre un secret. Activez Vérifier la signature et collez le secret partagé pour un algorithme HS, ou une clé publique pour un RS, PS ou ES : la signature est réellement testée — HS256/384/512, RS256/384/512, PS256/384/512 et ES256/384/512, via la WebCrypto du navigateur lui-même.
La clé que vous collez est traitée différemment de toute autre saisie sur ce site : elle n’est jamais écrite dans le localStorage ni restaurée au rechargement. Rien de tout cela — ni le jeton, ni la clé — n’est envoyé, et aucun serveur ne pourrait les recevoir.
Questions fréquentes
Peut-on coller un vrai JWT dans ce décodeur sans risque ?
Oui. Le jeton est décodé par du JavaScript dans votre propre onglet et il n’existe aucun backend où l’envoyer — coupez le réseau, le décodeur fonctionne toujours. Cela compte davantage pour les JWT que pour la plupart des données : un jeton est une identification vivante, et le coller sur un site qui l’envoie à un serveur revient à céder tout ce qu’il autorise.
Décoder un JWT signifie-t-il qu’il est valide ?
Non, et la distinction compte. L’en-tête et la charge utile sont encodés en base64url, pas chiffrés : quiconque détient le jeton peut les lire, et c’est pourquoi un JWT n’est jamais un endroit où mettre un secret. Seule la vérification de la signature avec la bonne clé vous dit que le jeton est authentique, intact, et que ses claims sont dignes de confiance.
Quels algorithmes de signature peut-il vérifier ?
HS256, HS384 et HS512 avec un secret partagé, ainsi que RS256/384/512, PS256/384/512 et ES256/384/512 avec une clé publique fournie sous forme de bloc PEM, de JWK isolé ou de JWKS entier — auquel cas le kid du jeton choisit la clé. La vérification s’appuie sur la WebCrypto intégrée au navigateur : aucun matériel de clé n’est transmis.
Ma clé ou mon secret de signature sont-ils enregistrés ?
Non. Tous les autres outils du site enregistrent votre saisie dans le localStorage pour qu’un rechargement ne fasse pas perdre votre travail ; la clé de vérification en est délibérément exclue. Elle reste en mémoire, sert au contrôle, et disparaît dès que vous quittez la page.
Pourquoi mon jeton apparaît-il comme expiré ?
Le claim exp est un NumericDate — des secondes depuis 1970 — et le décodeur l’affiche comme une vraie date, accompagnée du temps écoulé depuis. Un jeton expiré est la cause la plus fréquente d’un 401 soudain sur une API qui fonctionnait l’instant d’avant. Un claim nbf situé dans le futur produit le même effet à l’autre extrémité.