Décodeur de JWT

Un JSON Web Token ressemble à un bloc de caractères illisible, mais il s'agit en réalité de trois parties encodées en Base64URL et séparées par des points : un en-tête, un payload et une signature. Décoder l'en-tête et le payload n'a rien d'un chiffrement — n'importe qui possédant le token peut lire les claims qu'il contient, ce qui explique justement pourquoi des données sensibles ne devraient jamais être placées dans le payload d'un JWT. Le problème, c'est que les tokens que l'on a besoin d'inspecter sont rarement de simples données de test jetables. Il s'agit souvent d'un token de session bien réel provenant d'une application en production, d'un token d'accès API, ou d'un cookie de connexion récupéré directement depuis les outils de développement du navigateur pendant une session de debug — un identifiant véritable qui, entre de mauvaises mains, donne un accès bien réel. Coller ce token sur un site quelconque revient à confier votre session à un serveur dont vous ne savez rien.

Cet outil ne fait jamais cela. L'en-tête et le payload sont décodés en JavaScript pur, exécuté dans votre navigateur dès que vous collez un token — séparation sur les points, décodage Base64URL, analyse en JSON — et rien n'est transmis nulle part. La vérification de signature fonctionne selon le même principe, grâce à la Web Crypto API (`SubtleCrypto`) intégrée à tous les navigateurs modernes : les algorithmes HMAC (HS256, HS384, HS512) sont vérifiés à l'aide d'un secret que vous saisissez, et les algorithmes RSA (RS256, RS384, RS512) à l'aide d'une clé publique que vous collez au format PEM. Le secret cryptographique comme la vérification elle-même restent locaux à l'onglet ; rafraîchissez la page et tout disparaît — token, secret, clé.

Collez un token pour voir son en-tête et son payload mis en forme lisiblement, accompagnés d'une lecture des claims standard `exp`, `iat` et `nbf` convertis en date lisible, avec un badge "Expiré" bien visible si le `exp` du token est déjà dépassé — pratique pour confirmer qu'un rapport de bug du type "j'ai été déconnecté" n'est en réalité qu'un token expiré. Si l'algorithme est HS256/384/512 ou RS256/384/512, saisissez le secret ou la clé publique correspondants pour vérifier si la signature est authentique ou si elle a été altérée. Les algorithmes hors de cette liste (comme ES256 ou le `none` non signé) se décodent tout de même correctement, mais la vérification n'est pas proposée plutôt que de simuler un résultat. Pour le développement local, les champs d'en-tête et de payload modifiables permettent d'ajuster un claim — par exemple changer un identifiant utilisateur ou un rôle — puis de re-signer le token avec le même secret HS256 que celui utilisé par votre serveur de test, une méthode courante pour tester une logique d'autorisation sans avoir à relancer tout un flux de connexion.

Comme le payload d'un JWT devient un JSON simple et lisible une fois décodé, il s'associe naturellement à l'outil Formateur & Validateur JSON si vous avez besoin d'examiner de plus près un claim profondément imbriqué. Un rappel de sécurité qui mérite d'être répété : puisque le décodage ne nécessite aucun secret, considérez tout token comme sensible dès que vous avez terminé de l'inspecter, et renouvelez les identifiants qui n'étaient censés être que temporaires si vous n'êtes pas certain de l'endroit où ils ont pu être collés avant d'arriver ici.