Décodeur JWT
Collez un JWT pour voir son en-tête et son payload décodés, son expiration, et vérifier sa signature HMAC.
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "u_4821",
"nom": "Awa Diallo",
"role": "admin",
"iat": 1700000000,
"exp": 1700003600
}Comment fonctionne un JWT
Un JWT (JSON Web Token) est une chaîne de trois segments séparés par des points — en-tête.payload.signature — servant à transporter une identité vérifiable entre un serveur et un client. L'en-tête et le payload sont deux objets JSON encodés en Base64URL : lisibles par quiconque, sans aucune clé. La signature, elle, est calculée sur ces deux segments avec une clé secrète.
Le Base64URL est une variante du Base64 adaptée aux URL : les caractères + et / deviennent - et _, et le remplissage = est supprimé. Ce n'est pas du chiffrement, seulement une manière d'écrire des octets en texte : un JWT ne protège donc jamais la confidentialité de son contenu, uniquement son intégrité. N'y placez pas de mot de passe, de numéro de carte ni de donnée que l'utilisateur ne doit pas voir.
Ce que cet outil vérifie, et ce qu'il ne vérifie pas
Le décodage est systématique et sans clé. La vérification de signature, elle, est optionnelle et limitée aux algorithmes HMAC : vous saisissez le secret, l'outil recalcule HMAC(en-tête.payload) avec crypto.subtle en SHA-256, SHA-384 ou SHA-512 selon l'algorithme choisi, puis compare le résultat au troisième segment. Un jeton signé en RS256 ou ES256 s'affiche normalement, mais sa signature reste non contrôlée.
Trois autres contrôles restent à la charge du serveur, jamais du client : refuser un jeton dont l'en-tête annonce alg: none, imposer l'algorithme attendu au lieu de faire confiance à celui déclaré dans l'en-tête, et valider aud et iss. Un décodeur ne remplace aucune de ces vérifications : il sert à comprendre un jeton, pas à l'autoriser.
Quand utiliser un décodeur JWT
- Une API répond 401 sans explication — décoder le jeton envoyé montre immédiatement si son
expest dépassé, si lesubcorrespond au bon compte, ou si l'audvise un autre service que celui appelé. - Un rôle ou une permission ne prend pas effet — les claims personnalisés (
role,scope,tenant_id) sont figés au moment de l'émission : un droit accordé après coup n'apparaît qu'après un nouveau jeton. - Un décalage d'horloge entre services — comparer
iatetexpaux dates réelles révèle un serveur mal synchronisé qui rejette des jetons pourtant frais. - Valider une intégration en développement — vérifier avec le secret HMAC de recette qu'un jeton produit par votre propre code est bien signé comme prévu.
Les claims standards (RFC 7519)
| Claim | Nom | Rôle |
|---|---|---|
| iss | Issuer | Qui a émis le jeton (URL ou identifiant du service d'authentification). |
| sub | Subject | À qui il se rapporte — le plus souvent l'identifiant interne de l'utilisateur. |
| aud | Audience | Pour quel destinataire il est valide ; une API doit rejeter un jeton dont l'audience n'est pas la sienne. |
| exp | Expiration | Timestamp Unix en secondes après lequel le jeton doit être refusé. |
| nbf | Not before | Timestamp Unix avant lequel le jeton n'est pas encore valide. |
| iat | Issued at | Date d'émission, utile pour mesurer l'âge du jeton. |
| jti | JWT ID | Identifiant unique du jeton, base d'une liste de révocation. |
Tous ces claims sont facultatifs au sens de la norme : c'est le service qui décide lesquels il impose. Les claims propres à une application (rôle, permissions) viennent s'y ajouter librement.
Algorithmes de signature
| alg | Famille | Clé | Sur cette page |
|---|---|---|---|
| HS256 / HS384 / HS512 | HMAC + SHA-2 | Un secret partagé, identique côté émission et vérification | Vérifié par cet outil |
| RS256 / RS384 / RS512 | RSA + SHA-2 | Clé privée pour signer, clé publique pour vérifier | Décodé, signature non vérifiée |
| ES256 / ES384 / ES512 | ECDSA + SHA-2 | Paire de clés sur courbe elliptique | Décodé, signature non vérifiée |
| none | Aucune | Aucune — signature vide | À refuser systématiquement côté serveur |
L'en-tête et le payload d'un JWT sont encodés en Base64URL, pas chiffrés : les décoder ne demande aucune clé et peut donc se faire entièrement côté navigateur. C'est exactement ce que fait cet outil — il applique un décodage Base64URL puis un JSON.parse sur les deux premiers segments, en JavaScript, dans votre page. Aucun jeton n'est transmis sur le réseau.
Décoder ne fait que lire le contenu : n'importe qui peut le faire, sans secret ni clé. Un JWT n'est donc jamais un endroit où mettre une donnée confidentielle. Vérifier consiste à recalculer la signature à partir de l'en-tête, du payload et de la clé attendue, puis à la comparer à celle du jeton : c'est cette étape, et elle seule, qui prouve que le contenu n'a pas été modifié après émission.
Non. La vérification proposée couvre uniquement les algorithmes HMAC — HS256, HS384 et HS512 — à partir du secret que vous saisissez. Un jeton signé en RS256 ou ES256 est correctement décodé et affiché, mais sa signature n'est pas contrôlée : elle exigerait la clé publique de l'émetteur, dans un format que cet outil ne prend pas en entrée.
Sa signature reste mathématiquement valide indéfiniment : c'est le serveur qui doit comparer le claim exp à l'heure courante et refuser le jeton. Un service qui vérifie la signature mais oublie l'expiration accepte donc des jetons périmés. L'outil affiche exp, iat et nbf convertis en date lisible et signale explicitement un jeton expiré ou pas encore valide.
Pas directement, et c'est la principale limite du format : un JWT est autoporteur, le serveur n'a besoin d'aucun état pour le valider — donc rien à supprimer pour l'invalider. Les stratégies usuelles sont une durée de vie courte (quelques minutes) associée à un jeton de rafraîchissement, ou une liste de révocation côté serveur indexée sur le claim jti, ce qui réintroduit l'état qu'on cherchait à éviter.