100 % local — vos données ne quittent jamais votre navigateur

JWT en JSON — lisez les claims à l’intérieur

Décodez l’en-tête et le payload d’un JWT, signature non vérifiée. Vous lisez exp, iss et les scopes, ce qui dit en général pourquoi un jeton est refusé.

Instantané Privé Zéro cookie
Indentation

Entrée JWT

Sortie JSON

Ce que fait cet outil

Un jeton entre, son en-tête et sa charge utile sortent en JSON.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpM
{
  "header": {
    "alg": "HS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "1234567890"
  }
}

Les deux segments sont en Base64URL, qui est un encodage et non un chiffrement : quiconque tient le jeton peut les lire, ici ou en trois lignes de code. La signature n’est montrée nulle part, parce qu’il n’y a rien à y lire — c’est une preuve, et prouver demande une clé.

Décoder n’est pas vérifier

La charge utile ci-dessus dit que le sujet est 1234567890. Qu’elle le dise ne prouve rien : changez le texte, réencodez-le, et vous obtenez un jeton qui se décode aussi proprement et qui échoue à la vérification. Cette page ne peut pas faire la différence, et aucun décodeur ne le peut — c’est tout l’objet de la signature.

Donc : un décodeur sert à voir ce qu’un jeton prétend, votre serveur et votre clé servent à décider s’il faut le croire. Si les deux se contredisent un jour, c’est la signature qui a raison.

Trois segments, et trois seulement

Not a JWT: expected header.payload.signature, found 2 segments

Un JWT compact en a exactement trois. Deux ou quatre étaient décodés tout de même : un jeton coupé par un copier-coller revenait avec l’air parfaitement sain — un défaut trouvé en écrivant cette page puis corrigé. Cinq segments, c’est un autre format : un JWE, dont la charge est chiffrée plutôt qu’encodée, et le message le dit au lieu d’échouer sur un décodage.

Lire la charge utile

  • Les longs identifiants numériques survivent. Un sub de vingt chiffres traverse chiffre pour chiffre, au lieu d’être arrondi vers un voisin par un nombre JavaScript.
  • exp, iat et nbf sont des horodatages Unix. En secondes, pas en millisecondes, comme le veut la spécification. L’outil de timestamp de ce site les transforme en dates.
  • Les revendications sont ce que l’émetteur y a mis. alg, typ, sub, iss et aud sont normalisées ; le reste est une convention entre vos deux bouts.

Confidentiel par conception

Tout s’exécute localement dans votre navigateur en JavaScript. Vos données ne sont jamais envoyées sur un serveur, ce qui rend l’outil sûr pour des contenus sensibles, et il fonctionne hors ligne.

Questions fréquentes

La signature est-elle vérifiée ?
Non, et aucun outil de navigateur ne le peut : vérifier demande le secret ou la clé publique, c’est-à-dire précisément ce qu’il ne faut coller nulle part. Décoder vous dit ce que le jeton affirme ; vérifier vous dit s’il faut le croire. La charge utile que vous voyez ici a pu être tapée par n’importe qui — le Base64URL est un encodage, pas une protection. Vérifiez côté serveur, avec votre clé.
Mon jeton est-il envoyé quelque part ?
Non. Le décodage se fait dans votre navigateur et rien ne quitte la page — bon à savoir, car un jeton de production collé dans un décodeur en ligne est un identifiant confié à un inconnu. Préférez tout de même un jeton expiré ou de test quand vous le pouvez : cette page ne peut rien promettre sur la machine où vous tapez.
Pourquoi mon jeton est-il refusé ?
Parce qu’il n’a pas trois segments. Un JWT sous forme compacte, c’est `header.payload.signature`, et deux ou quatre segments étaient décodés quand même : un jeton tronqué par un copier-coller revenait avec l’air d’aller bien. Cinq segments, c’est un JWE — sa charge est chiffrée et non simplement encodée, et rien ne la lit sans la clé. Le message dit maintenant dans quel cas vous êtes.

Convertisseurs associés