Diagnostiquer une erreur 401
Une API refuse votre requête : décodez le jeton Bearer pour voir s’il est expiré, si l’audience aud correspond bien à l’API appelée ou si l’émetteur iss est le bon environnement.
Collez un JSON Web Token : l’en-tête et le payload sont décodés en JSON pendant la saisie, avec un résumé de l’algorithme, de l’émetteur, de l’audience et des dates exp, iat et nbf en heure locale.
algtypkidisssubaudexpiatnbfLe décodage ne vérifie pas la signature : n’importe qui peut lire un JWT. Pour contrôler la signature, utilisez le vérificateur JWT.
Le décodeur JWT affiche en clair l’en-tête et le payload d’un JSON Web Token au fur et à mesure que vous le collez. Il s’adresse aux développeurs, testeurs et équipes support qui doivent comprendre rapidement ce que contient un jeton d’accès ou un ID token : algorithme, émetteur, audience et dates de validité. Il lit le jeton mais ne vérifie pas sa signature.
Un JWT signé (RFC 7519, au format JWS compact de la RFC 7515) est composé de trois segments séparés par des points : en-tête, payload et signature. Les deux premiers sont du JSON encodé en Base64URL, une variante du Base64 qui remplace + et / par - et _ et supprime le remplissage =. Le décodeur découpe le jeton, convertit chaque segment en texte UTF-8 puis l’analyse comme JSON. Par exemple, le segment eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 correspond à {"alg":"HS256","typ":"JWT"}.
Le résumé extrait ensuite les champs utiles : alg et typ dans l’en-tête, iss (émetteur), sub (sujet) et aud (audience) dans le payload. Les claims exp, iat et nbf sont des NumericDate, c’est-à-dire un nombre de secondes depuis le 1er janvier 1970 UTC : 1767225600 correspond au 1er janvier 2026 à 00:00 UTC. L’outil les convertit en heure locale et indique si le jeton est valide, expiré ou pas encore valide. Un avertissement apparaît si l’en-tête déclare alg: none, c’est-à-dire un jeton non signé.
Collez le jeton complet, avec ses trois parties séparées par des points. Le décodage démarre pendant la saisie, sans bouton à cliquer.
Les deux segments s’affichent en JSON formaté : algorithme et type dans l’en-tête, claims standards et personnalisés dans le payload.
Vérifiez l’algorithme, iss, sub, aud et les dates exp, iat et nbf en heure locale avec leur statut. Pour contrôler la signature, passez au vérificateur JWT.
Une API refuse votre requête : décodez le jeton Bearer pour voir s’il est expiré, si l’audience aud correspond bien à l’API appelée ou si l’émetteur iss est le bon environnement.
Après une connexion OpenID Connect (Auth0, Keycloak, Entra ID, Cognito), consultez les claims personnalisés comme roles, groups ou scope pour comprendre pourquoi un utilisateur n’a pas accès à une page.
Comparez iat et exp pour vérifier que votre fournisseur d’identité émet bien des jetons d’accès de 5, 15 ou 60 minutes, comme prévu par votre configuration.
Entrée
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cRésultat
En-tête : {"alg":"HS256","typ":"JWT"} ; Charge utile : {"sub":"1234567890","name":"John Doe","iat":1516239022} ; signature non vérifiéeOui. L’en-tête et le payload sont seulement encodés en Base64URL, pas chiffrés : n’importe qui possédant le jeton peut les lire. La clé n’est nécessaire que pour vérifier la signature, ce que fait le vérificateur JWT et non ce décodeur.
Non, un JWT signé (JWS) est lisible par tous ; la signature garantit seulement qu’il n’a pas été modifié. Ne placez donc jamais de mot de passe ou de donnée confidentielle dans le payload. Si le contenu doit rester secret, il faut utiliser un JWE (RFC 7516).
exp est la date d’expiration, iat la date d’émission et nbf la date avant laquelle le jeton ne doit pas être accepté. Ce sont des secondes Unix (NumericDate, RFC 7519) et non des millisecondes. L’outil les affiche en heure locale avec le statut valide, expiré ou pas encore valide.
alg: none signifie que le jeton n’est pas signé du tout. Un serveur qui l’accepte laisse n’importe qui fabriquer ses propres jetons, une faille connue recensée dans la RFC 8725. Une application en production doit toujours imposer la liste des algorithmes autorisés.
Le jeton est souvent tronqué lors du copier-coller, contient encore le préfixe Bearer ou des guillemets, ou n’a pas trois segments. Un segment qui n’est pas du Base64URL valide ou dont le contenu n’est pas du JSON provoque aussi une erreur.
Un jeton d’accès valide est un identifiant : quiconque le récupère peut l’utiliser jusqu’à son expiration. Ici, le décodage est fait dans votre navigateur et le jeton n’est envoyé à aucun serveur. Préférez tout de même des jetons de test ou déjà expirés lorsque c’est possible.
Workflow recommandé
Découvrez les outils qui interviennent naturellement avant, après ou en complément de celui-ci.
Encodez un texte en Base64 ou décodez une chaîne Base64 pour retrouver son contenu d’origine.
Formatez, minifiez et validez un document JSON pour le rendre plus lisible ou plus compact.
Calculez en une fois les empreintes MD5, SHA-1, SHA-256, SHA-384 et SHA-512 d’un texte ou d’un fichier.
Vérifiez la signature d’un JWT avec un secret HMAC ou une clé publique JWK, JWKS ou PEM, puis contrôlez exp, nbf, iss et aud.
Apprenez ce qu’un JWT contient, ce que sa signature prouve réellement et pourquoi décoder un jeton ne revient pas à le vérifier.
Comprenez comment OAuth 2.0, PKCE, JWT, JWK et JWKS s’articulent sans les confondre : autorisation, jetons, clés publiques et vérification.