Décodeur JWT

Ce décodeur JWT affiche en clair l'en-tête et la charge utile (payload) d'un JSON Web Token. Un JWT n'est pas chiffré par défaut : ses segments sont simplement encodés en Base64url, donc n'importe qui peut en lire le contenu. Coller un jeton actif dans un décodeur en ligne classique revient pourtant à confier vos claims d'authentification, identifiant utilisateur et rôles compris, à un tiers. Ici, le décodage est effectué par un module Rust compilé en WebAssembly, dans l'onglet : aucun octet du token ne quitte votre machine.

Comment décoder un JWT

1. Collez le token dans le champ JWT Token. Les espaces et retours à la ligne en début et fin sont ignorés.
2. Retirez le préfixe Bearer si vous l'avez copié depuis un en-tête Authorization : le champ doit contenir uniquement le jeton.
3. Cliquez sur Decode.
4. Lisez les panneaux Header et Payload, présentés en JSON indenté, et copiez l'un ou l'autre avec son bouton de copie.

Structure d'un JWT : en-tête, charge utile, signature

Un JWT se compose de trois segments encodés en Base64url et séparés par des points : header.payload.signature. L'en-tête indique l'algorithme de signature (HS256, RS256, ES256…) et le type de jeton. La charge utile contient les claims, c'est-à-dire les données : les claims enregistrés comme iss (émetteur), sub (sujet), aud (audience), exp (expiration) et iat (date d'émission), plus les claims personnalisés de votre application. La signature est calculée sur les deux premiers segments et prouve que le jeton n'a pas été modifié.

Lire les claims les plus courants

• exp, iat, nbf : expiration, émission et « pas avant ». Ce sont des timestamps Unix en secondes, affichés tels quels. Collez-en un dans le convertisseur de timestamp Unix pour obtenir la date et savoir si le jeton a expiré.
• iss et aud : qui a émis le jeton et à quelle API il est destiné. Une incohérence ici est une cause fréquente de réponse 401.
• sub : le sujet, généralement l'identifiant de l'utilisateur ou du client.
• scope, roles, identifiant de tenant : claims personnalisés ou propres au fournisseur (Keycloak, Auth0, Azure AD…) qui pilotent les autorisations.
• alg et kid dans l'en-tête : l'algorithme et l'identifiant de clé qui sert à choisir la clé de vérification dans un JWKS.

Décoder n'est pas vérifier

C'est le point essentiel. Décoder consiste à transformer le Base64url en JSON lisible, ce que tout le monde peut faire. Vérifier est une étape cryptographique distincte qui contrôle la signature avec un secret ou une clé publique pour confirmer que le jeton est authentique et intact. Cet outil décode seulement : le segment de signature est ignoré. Ne considérez jamais un payload décodé comme une preuve d'identité en production ; la vérification doit se faire côté serveur, avec la bonne clé.

Erreurs et cas particuliers

• Pas trois segments : le jeton doit contenir exactement deux points. Un jeton chiffré (JWE) en compte cinq et ne peut pas être lu sans la clé ; il est refusé avec le message expected 3 parts separated by dots.
• Encodage invalide : les segments doivent être en Base64url sans remplissage =, comme l'exige la spécification. Un caractère parasite, par exemple l'espace de Bearer eyJ…, déclenche une erreur d'encodage.
• JSON invalide : l'en-tête et la charge utile doivent tous deux être des objets JSON valides.
• Signature : son contenu n'est pas lu. Un jeton non signé avec une signature vide (header.payload.) est décodé quand même.

Cas d'usage

• Déboguer une authentification : comprendre pourquoi une requête est rejetée en lisant exp (jeton expiré ?) ou aud (mauvaise audience ?).
• Contrôler des claims personnalisés : vérifier que rôles, scopes ou identifiant de tenant ont bien été ajoutés à la connexion.
• Découvrir un fournisseur d'identité : observer la structure de ses jetons avant une intégration OpenID Connect.

Par rapport à la ligne de commande

On peut décoder un payload dans un terminal en découpant sur les points et en décodant le segment central, mais le Base64url utilise - et _ et omet le remplissage : un simple base64 -d échoue souvent tant qu'on n'a pas remplacé ces caractères et ajouté les =. Cette page s'en charge et formate le JSON.

Confidentialité : le token reste dans l'onglet

Un jeton d'accès est un identifiant : tant qu'il n'a pas expiré, il peut être rejoué contre votre API. L'envoyer à un décodeur distant l'expose à la journalisation et à l'interception, et les claims contiennent souvent des données personnelles (e-mail, nom, identifiant) soumises au RGPD. Ici, le JWT est décodé entièrement côté client : rien n'est téléversé, transmis ni stocké. Fermez l'onglet et le jeton disparaît.

Questions fréquentes

L'outil vérifie-t-il la signature du JWT ?

Non. Il décode uniquement l'en-tête et la charge utile. La vérification exige le secret ou la clé publique et doit être faite par votre serveur ou une bibliothèque JWT.

Puis-je coller un jeton de production ?

Le jeton n'est envoyé nulle part : le décodage a lieu dans votre navigateur. Traitez néanmoins un jeton valide comme un mot de passe et évitez de le laisser dans un historique de presse-papiers ou un partage d'écran.

Que signifie « expected 3 parts separated by dots » ?

La saisie n'est pas un JWT signé : elle est peut-être tronquée, précédée d'un préfixe, opaque (un jeton d'accès qui n'est pas un JWT) ou chiffrée (JWE à cinq segments).

Comment savoir si le jeton a expiré ?

Lisez le claim exp dans la charge utile et convertissez-le en date avec le convertisseur de timestamp. Si la date est passée, le jeton a expiré.

Peut-il décoder un JWT chiffré (JWE) ?

Non. La charge utile d'un JWE est chiffrée et illisible sans la clé de déchiffrement.

Puis-je modifier les claims et re-signer le jeton ?

Non. L'outil fonctionne en lecture seule et ne crée ni ne signe de jetons.

Outils connexes : les segments d'un JWT sont encodés en Base64url, l'encodeur et décodeur Base64 sert donc à manipuler les valeurs brutes, et le formateur JSON met en forme un payload volumineux.