Inspectez un JWT et vérifiez sa signature avec un secret HMAC ou une clé publique JWK ou JWKS. Renseignez l’émetteur ou l’audience attendus pour les contrôler aussi ; le décodage seul ne prouve pas l’authenticité du jeton.
Fonctionne localement dans votre navigateurPour HS256/384/512, saisissez le secret partagé brut. Pour les algorithmes asymétriques, collez un document public JWK ou JWKS JSON.
Decode or verify a compact JWT to inspect its protected header and payload.
N’importe qui peut décoder une payload JWT. Traitez un jeton comme étant fiable uniquement après une vérification de signature réussie avec l'algorithme et la clé prévus, ainsi qu'une validation des revendications au niveau de l'émetteur, de l'audience, de l'heure et de l'application.
Collez un JWT compact : l’outil affiche son en-tête protégé et sa charge utile, puis vérifie la signature avec le matériel que vous fournissez — un secret partagé brut pour HS256/384/512, ou un document JWK ou JWKS public pour RS, PS, ES et EdDSA. L’émetteur ou l’audience attendus peuvent être contrôlés dans la même passe.
Décoder n’est pas vérifier. La page décode en local et le dit, et elle ne présente un jeton comme vérifié qu’après validation de la signature et des revendications enregistrées (exp, nbf, iss, aud). Rien n’est envoyé, aucune URL JWKS n’est récupérée et le matériel de clé n’est pas conservé.
Inspecter le jeton fait passer la charge utile dans un décodeur JWT et affiche l’en-tête protégé et la charge utile en JSON. La ligne d’état reste volontairement un avertissement : quiconque détient le jeton peut le lire, les revendications décodées ne sont donc qu’un aperçu de ce que le jeton prétend être.
Un jeton qui ne déclare aucun algorithme signé (alg none ou absent) se décode quand même ici : l’inspection n’exige jamais de signature. C’est la vérification de signature qui le refuse.
Avec un secret partagé, la signature est recalculée sur le texte exact du jeton puis comparée ; avec une clé publique, le JWK correspondant est importé et utilisé. Dans un document JWKS, la clé dont le kid correspond à l’en-tête du jeton est recherchée, et la première clé sert lorsque le jeton n’a pas de kid.
Les revendications enregistrées sont contrôlées dans la même passe : exp et nbf face à l’horloge courante, iss face à l’émetteur attendu et aud face à l’audience attendue lorsque ces champs sont remplis. La ligne d’état nomme le premier échec — signature invalide, contrôle d’exp ou de nbf, valeur iss ou aud inattendue ou absente — plutôt qu’une erreur générique.
Le résumé liste Algorithme, ID de clé, Émetteur, Audience, Sujet et Expiration ; un tableau d’audiences s’affiche en liste séparée par des virgules. Le panneau du dessous montre le jeton décodé en JSON indenté, avec protectedHeader et payload dans un même document.
Les deux panneaux sont du texte en lecture seule : le résultat se sélectionne et se copie, et une vérification réussie garde la même disposition qu’une inspection — rien ne masque le fait que la signature est ce qui rend les revendications fiables.
Tout se passe dans l’onglet avec la bibliothèque jose et la Web Crypto API. La page n’émet aucune requête pendant l’inspection ou la vérification, ne récupère jamais une URL JWKS — c’est vous qui collez le document — et le matériel de clé reste dans les champs du formulaire.
Le bouton d’exemple est le seul endroit où existe une clé privée, et elle ne quitte pas la page : la paire est générée dans le navigateur, le jeton y est signé, et le champ ne reçoit que le JWK public. Cela signifie aussi que la rotation des clés est manuelle ici : un JWKS renouvelé doit être collé à nouveau.