Décodeur JWT
Collez un JSON Web Token pour lire son header et son payload, savoir quand il expire et comprendre chaque claim. Votre token ne quitte jamais votre navigateur.
Fonctionne dans le navigateurSans inscriptionAucun envoi de données
Décoder n’est pas vérifier. N’importe qui peut lire le header et le payload d’un JWT, car ils sont simplement encodés en base64url. Cet outil montre ce que le token affirme ; il ne prouve pas que le token est authentique. Vérifiez toujours la signature côté serveur.
Header
Payload
Claims expliqués
Vérifier la signature (facultatif, HS256/HS384/HS512)
Vérifie une signature HMAC avec le secret que vous saisissez, via l’API Web Crypto de votre navigateur. Le secret ne quitte jamais cette page. Les tokens RSA/ECDSA nécessitent la clé publique de l’émetteur et ne sont pas vérifiés ici.
Comment utiliser : Décodeur JWT
- Collez le token dans la zone Token encodé. Un préfixe
Bearerprovenant d’un en-tête Authorization est ignoré. - Le header et le payload sont décodés instantanément et affichés en JSON formaté.
- Lisez le tableau Claims expliqués :
exp,iatetnbfsont convertis en dates avec des durées du type « expire dans » / « expiré il y a ». - Consultez la barre d’état pour les problèmes d’expiration et les avertissements pour les réglages risqués comme
alg: none. - Saisissez éventuellement le secret partagé pour vérifier localement une signature HS256, HS384 ou HS512.
Que contient un JWT ?
Un JSON Web Token (RFC 7519) est composé de trois chaînes base64url reliées par des points : header.payload.signature. Le header indique l’algorithme de signature (alg) et le type de token. Le payload contient les claims, comme l’identité de l’utilisateur et la date d’expiration du token. La signature est calculée sur les deux premières parties avec un secret ou une clé privée.
Décoder n’est pas vérifier
Le header et le payload sont seulement encodés, pas chiffrés : toute personne qui détient le token peut les lire. C’est pourquoi il ne faut jamais mettre de mots de passe ou de secrets dans le payload d’un JWT. Le décodage vous dit ce qu’un token affirme. Vérifier la signature, normalement sur votre serveur d’API avec une bibliothèque comme jose ou PyJWT, prouve qui l’a émis et qu’il n’a pas été modifié. Un serveur doit aussi contrôler exp, nbf, iss et aud, et rejeter les algorithmes inattendus.
Aide-mémoire des claims enregistrés
| Claim | Signification |
|---|---|
iss | Émetteur : qui a créé et signé le token |
sub | Sujet : généralement l’ID de l’utilisateur |
aud | Audience : l’API à laquelle le token est destiné |
exp | Date d’expiration, en secondes depuis l’epoch Unix |
nbf | Non valide avant cette date |
iat | Date d’émission |
jti | ID unique du token, utile pour les listes de révocation |
Déboguer les erreurs « token expired »
Si une API rejette un token qui semble récent, comparez exp et nbf avec l’horloge du serveur. Un léger décalage d’horloge entre machines est courant : la plupart des bibliothèques tolèrent 30 à 60 secondes de marge. Vérifiez aussi que exp est bien en secondes : une valeur en millisecondes est un bug fréquent qui repousse l’expiration de plusieurs milliers d’années.
Questions fréquentes
Est-il sûr de coller ici un JWT de production ?
Cet outil vérifie-t-il la signature du JWT ?
Pourquoi mon token apparaît-il comme expiré ?
exp est dans le passé par rapport à l’horloge de votre ordinateur. Demandez un nouveau token, ou renouvelez-le avec votre refresh token. Si les dates semblent fausses, vérifiez un éventuel décalage d’horloge ou une valeur exp écrite en millisecondes.Quelle différence entre JWT, JWS et JWE ?
Pourquoi alg « none » est-il dangereux ?
alg: none et n’accepter que l’algorithme précis qu’ils attendent.