Décodeur JWT et débogueur : décode et vérifie des tokens en ligne

Oui. Le décodeur et débogueur JWT fonctionne directement sur cette page, dans ton navigateur, sans compte, sans inscription et sans installation.

Non. Le décodage, la signature et sa vérification s’effectuent exclusivement dans ton navigateur, à l’aide de la Web Crypto API pour la cryptographie. Le token, le secret et la clé publique ne sont pas envoyés. Les vrais JWT contiennent toutefois souvent des données d’accès à une session ou à une API : mieux vaut utiliser des tokens de test.

Oui. Un JWT n’est pas chiffré : l’en-tête et le payload sont simplement encodés en Base64URL et lisibles par tous. Le secret ou la clé publique ne sert qu’à vérifier la signature et, pour HS256, HS384 et HS512, à signer à nouveau. Décoder un token ne prouve donc pas son authenticité : seule la vérification de la signature le permet.

Pour HS256, HS384 et HS512, saisis le secret. Si l’en-tête indique RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 ou ES512, un champ pour la clé publique au format PEM « BEGIN PUBLIC KEY » (SPKI) apparaît à la place. L’outil n’accepte pas RSA PUBLIC KEY (PKCS#1) ni les certificats. Le résultat s’affiche en haut : « Valide », « Invalide » ou « Non vérifié » si aucun secret ou clé n’est fourni. L’outil ne vérifie pas les autres algorithmes.

Si le payload contient exp, iat ou nbf sous forme numérique, l’outil affiche ces claims au-dessus du payload sous forme de dates en UTC. Pour exp, il indique le temps restant avant l’expiration du token ou le temps écoulé depuis son expiration ; une valeur exp dépassée apparaît en rouge. Si nbf est dans le futur, tu vois à partir de quand le token sera valide.

Oui. Modifie directement l’en-tête ou le payload, par exemple exp, les rôles ou tes propres claims, ou choisis un autre algorithme. Dès que tu effectues une modification, un nouveau token signé avec ton secret est généré en direct dans le champ « Encoded (JWT) ». La signature ne fonctionne qu’avec HS256, HS384 et HS512 : les algorithmes RS, PS et ES nécessiteraient une clé privée, que l’outil n’utilise pas.

Copie uniquement la partie après « Bearer » et colle-la. Le préfixe n’est pas supprimé automatiquement, et un JWT doit comporter exactement trois parties séparées par des points (en-tête.payload.signature). Avec le préfixe, l’en-tête ne peut pas être lu et l’outil affiche une erreur.

Un JWT se compose de trois parties encodées en Base64URL et séparées par des points : un en-tête (avec, par exemple, alg et typ), un payload contenant les claims et une signature. L’exemple prérempli montre cette structure : un token HS256 avec sub, name et iat, vérifié comme « Valide » avec le secret d’exemple.