Décodeur JWT pour un jeton qui pose problème
Collez le jeton, lisez les claims. Le décodeur JWT coupe la chaîne aux points, convertit les deux premières parties de Base64URL en texte et les affiche en JSON indenté. Vous voyez l’algorithme, l’identifiant, les rôles et les dates, sans écrire une ligne de code.
Cinq gestes dans l’outil
- Collez le jeton dans « Jeton JWT encodé ». Le champ contient d’abord un exemple. « Charger un exemple » le rétablit et « Effacer » vide le champ.
- Le header s’affiche à gauche, souvent avec
algettyp. - Le payload s’affiche à droite, avec des claims comme
sub,iatetexp. - La barre d’état au-dessus indique si le jeton est expiré et donne la date au format de votre langue.
- Le bouton de copie de chaque panneau place le JSON formaté dans le presse-papiers.
Ce que le statut vert ne dit pas
La signature n’est pas vérifiée. L’outil ne lit jamais la troisième partie et n’a aucun champ pour une clé. Le vert signifie seulement que exp est dans le futur selon l’horloge de votre appareil. Un jeton falsifié avec un bon exp aurait le même aspect.
Les claims nbf et iat restent des nombres bruts, sans conversion ni test. Sans exp, l’outil affiche « Pas de date de fin (signature non vérifiée) ». Un Bearer au début n’est pas retiré et provoque une erreur de décodage Base64. Les jetons chiffrés (JWE, cinq parties) échouent aussi. Deux parties suffisent en revanche.
Le décodage se fait en JavaScript sur votre appareil. Aucune requête ne part quand vous saisissez ou collez, et le jeton n’est pas conservé. Le presse-papiers n’est touché que par les boutons de copie.
Trois situations où l’outil fait gagner du temps
- Votre API renvoie 401 : le jeton a-t-il expiré, et depuis quand ?
- Un nouveau fournisseur d’identité place-t-il le bon tableau
rolesdans le jeton ? - Une application mobile envoie le jeton au mauvais backend. Comparez
subetexpavec le jeton attendu.