Décodez l'en-tête et le payload d'un JWT, inspectez les claims et l'expiration — sans que le token quitte votre navigateur.
Un JSON Web Token (JWT, RFC 7519) se compose de trois segments encodés en Base64URL séparés par des points : un en-tête qui nomme l'algorithme de signature, un payload portant les claims — qui a émis le token, pour qui, et jusqu'à quand il est valide — et une signature. Les JWT sont l'identifiant porteur standard d'OAuth 2.0 et d'OpenID Connect, raison pour laquelle le débogage d'un flux de connexion ou d'une intégration d'API commence si souvent par la question : que contient réellement ce token ?
Ce décodeur découpe le token sur les points, restaure le bourrage Base64URL, décode chaque segment en UTF-8 et met le JSON en forme. Il met en évidence les claims enregistrés — iss (émetteur), sub (sujet), aud (audience), iat (émis à), nbf (pas avant) et exp (expiration) — en convertissant les horodatages numériques, qui comptent les secondes depuis l'epoch Unix, en dates UTC lisibles. L'expiration est aussi comparée à votre horloge : l'état vous dit d'un coup d'œil si le token est encore valide et pour combien de temps, ou depuis combien de temps il a expiré. Une entrée malformée produit une erreur claire et lisible plutôt qu'une exception cryptique.
Une chose doit être dite le plus fort possible : décoder un JWT n'est pas le valider. L'en-tête et le payload sont simplement encodés en Base64URL — n'importe qui peut les lire et n'importe qui peut les forger. Seule la signature, vérifiée avec le secret ou la clé publique de l'émetteur, prouve qu'un token est authentique, et cet outil ne le fait délibérément pas : la vérification de signature appartient à votre serveur, avec une vraie bibliothèque JWT. Pour la même raison, ne mettez jamais de mots de passe ni d'autres secrets dans un payload de JWT — encodé n'est pas chiffré. Le token que vous collez ici est décodé entièrement dans votre navigateur et jamais transmis, mais traitez les tokens de production comme les identifiants qu'ils sont.
Non — il décode seulement l'en-tête et le payload, et le rappelle sur chaque résultat. Un token décodé ne prouve rien quant à son authenticité : vérifiez la signature sur votre serveur avec la clé de l'émetteur et une vraie bibliothèque JWT avant de faire confiance à un claim.
Non. Dans un JWT signé standard (JWS), l'en-tête et le payload sont seulement encodés en Base64URL, lisibles par quiconque détient le token. Les JWT chiffrés (JWE) existent mais sont rares ; ne stockez jamais de secrets dans le payload d'un JWT ordinaire.
Ce sont des horodatages en secondes depuis l'epoch Unix : iat est le moment d'émission du token, nbf le moment avant lequel il doit être rejeté, et exp son expiration. Cet outil convertit les trois en dates UTC lisibles et calcule l'état d'expiration pour vous.
Les causes les plus courantes : coller quelque chose qui n'est pas un JWT compact (il doit avoir exactement trois parties séparées par des points), un token tronqué par un copier-coller, ou des caractères parasites autour. Le préfixe « Bearer » est géré automatiquement ; tout le reste autour du token ne l'est pas.
Non. Le décodage se fait à 100 % localement en JavaScript — le token n'est jamais transmis, journalisé ni stocké. Malgré tout, un JWT de production est un identifiant actif : évitez d'en partager des captures d'écran et révoquez les tokens que vous soupçonnez d'avoir été exposés.
Vai.la transforme n'importe quelle URL en lien court avec statistiques de clics, QR Code et votre propre biolink.
Vai.la n'est pas responsable de l'utilisation des outils ni des décisions prises sur la base de leurs résultats.