Explorez n'importe quel JWT — en-tête, charge utile et expiration

Collez le JWT encodé (la longue chaîne eyJ…) dans la zone de saisie. L'outil le découpe au niveau des deux points, décode l'en-tête et la charge utile en Base64URL et affiche le JSON de chacun ainsi que le segment de signature brut — le tout sans aucune requête réseau.

Non. Le décodeur se contente d'analyser le token : il ne vérifie pas la signature à l'aide d'une clé secrète ou publique, car la vérification nécessite le matériel de clé de l'émetteur. Utilisez une bibliothèque JWT côté serveur pour la vérification en production ; cet outil sert à l'inspection et au débogage.

Vous obtenez l'en-tête (algorithme et identifiant de clé), les revendications de la charge utile (sub, iss, aud, iat, exp et toute revendication personnalisée) et la signature brute. Les revendications d'horodatage standard sont mises en forme sous forme de dates lisibles afin que vous puissiez repérer les jetons périmés en un coup d'œil.

Si la charge utile contient la revendication standard « exp », l'outil la compare à l'heure actuelle et affiche soit « Valide jusqu'au », soit « Token expiré le » avec l'horodatage exact. Les tokens sans revendication exp sont signalés comme n'ayant pas de date d'expiration.

Quiconque lit la charge utile d'un JWT peut l'utiliser jusqu'à son expiration ; les jetons de production doivent donc rester dans des outils privés. Ce décodeur fonctionne entièrement dans votre navigateur et ne transmet jamais le jeton, mais la règle la plus sûre consiste à décoder de préférence des jetons de développement à courte durée de vie.

Un JWT comporte trois segments encodés en Base64URL séparés par des points : l'en-tête (l'algorithme de signature), la charge utile (les revendications que l'émetteur souhaite voir le vérificateur accepter) et la signature (un MAC ou une signature numérique portant sur header.payload). Le décodage ne nécessite jamais de clé — seule la vérification en a besoin.

Un jeton compact et compatible URL composé de trois segments Base64URL — en-tête, charge utile et signature — qui transporte des revendications signées comme un identifiant utilisateur et une date d'expiration. Il est largement utilisé pour les sessions de connexion sans état et la sécurisation des requêtes API. Collez-en un ci-dessus pour inspecter son en-tête et sa charge utile.

Sous l'en-tête et la charge utile décodés, collez le secret de signature (pour HS256) ou la clé publique de l'émetteur au format PEM ou JWK (pour RS256, ES256 et similaires) dans le champ Vérifier la signature, puis cliquez sur Vérifier. Le badge qui apparaît indique si la signature est valide, invalide, ou utilise un algorithme que le vérificateur côté navigateur ne prend pas en charge — le tout calculé localement, sans envoyer le jeton ni la clé où que ce soit.

Pour les algorithmes HMAC comme HS256, vous collez la chaîne du secret partagé brut. Pour les algorithmes asymétriques comme RS256, RS384 ou ES256, il vous faut la clé publique de l'émetteur — jamais la clé privée — fournie sous forme de bloc PEM ou de JWK ; coller la mauvaise moitié d'une paire de clés asymétrique fera échouer la vérification même si le jeton est valide.

Le panneau Vérifier la signature prend en charge tous les algorithmes JOSE courants : HS256/384/512 (HMAC avec un secret partagé), RS256/384/512 (RSASSA-PKCS1-v1_5 avec une clé publique RSA), PS256/384/512 (RSA-PSS avec une clé publique RSA) et ES256/384/512 (ECDSA sur la courbe P-256/P-384/P-521 correspondante). Les jetons signés avec « none » ou tout algorithme hors de cette liste sont toujours signalés comme non pris en charge plutôt que marqués valides, ce qui vous protège aussi de la classique falsification alg=none.

La cause la plus fréquente est le collage d'espaces superflus ou d'un retour à la ligne final dans le champ du secret — le vérificateur hache exactement les octets que vous saisissez, un artefact de copier-coller casse donc la correspondance. Vérifiez aussi que vous validez le jeton actuel : si le JWT a été réémis après que vous l'ayez copié, ou si le secret du fournisseur est encodé en base64 plutôt qu'une chaîne brute, décodez-le d'abord avant de le coller.

Cliquez sur Essayer un exemple de JWT pour charger un jeton HS256 de démonstration avec les revendications sub, name, iat et exp, afin de voir le décodage et la vérification d'expiration fonctionner avant de coller votre propre jeton. Une fois un jeton dans le champ, un bouton Effacer apparaît à côté pour vider la saisie en un clic.

Chacun des panneaux Header, Payload et Signature possède son propre bouton Copier dans son coin supérieur droit, qui copie uniquement le JSON de cette section (ou la chaîne de signature brute) dans votre presse-papiers. Il y a aussi un bouton principal Copier le Payload sous les panneaux pour le cas le plus courant : récupérer uniquement les claims à coller dans un débogueur ou un rapport de bug.

Copiez la valeur qui suit « Bearer » dans l'en-tête Authorization — la partie eyJ… est le JWT lui-même — puis collez-la dans le décodeur pour afficher instantanément l'en-tête, les revendications (claims) du payload et le statut d'expiration. Si vous copiez toute la chaîne « Bearer eyJ… », retirez d'abord le préfixe « Bearer » pour que le token comporte exactement trois parties séparées par des points.

Non — il s'agit d'un décodeur et visualiseur, pas d'un éditeur de JWT. Modifier le payload invaliderait la signature, donc tout serveur qui vérifie le jeton rejetterait la version altérée. Pour changer des claims, vous devez émettre un nouveau jeton signé avec le bon secret ou la bonne clé privée. Utilisez le décodeur pour lire et déboguer des jetons, pas pour les modifier.