Décoder un JWT (lire un token)

Comment ça marche

Collez le token dans le panneau de gauche tel que vous l'avez copié : un préfixe Bearer ou Authorization: resté accroché est retiré par l'outil, et un token cassé sur plusieurs lignes est recollé. La sortie montre trois blocs : l'en-tête (algorithme et type), le payload (les champs que le token transporte) et les champs de temps. Un payload contenant "exp": 1817121600, par exemple, est accompagné de la date calendaire correspondante et de l'indication que l'échéance est passée ou non ; iat (émis le) et nbf (invalide avant) sont convertis de la même façon, dans le fuseau que vous choisissez — UTC ou un décalage fixe de UTC+3. Le token n'est envoyé à aucun serveur ; examiner un vrai token d'un système où vous êtes connecté ne le fait donc pas sortir de votre appareil. Ce que l'outil ne fait volontairement pas : vérifier la signature. Lire le contenu ne prouve pas qu'il est intact — la vérification exige la clé secrète, et une clé secrète ne se colle dans aucune page web.

Cet outil est aussi connu sous le nom de jwt decoder en ligne, lire un token jwt, jwt decode.

Qu'est-ce que JWT (JSON Web Token) ?

Le JWT est un format texte en trois parties qui transporte identité et autorisations entre deux systèmes : l'en-tête nomme l'algorithme, le payload porte les champs, la signature atteste que le contenu n'a pas été modifié. Les parties sont séparées par des points et chacune est encodée en Base64URL — le contenu est donc emballé, pas chiffré. Après la connexion, le serveur remet un JWT à l'utilisateur ; aux requêtes suivantes, il le reconnaît en vérifiant la signature au lieu d'interroger une base de données. Cette conception rend le token portable, à un prix : quiconque le détient peut agir sous cette identité jusqu'à l'expiration.

Qu'est-ce que Base64URL ?

Le Base64URL est un encodage qui projette les données sur un alphabet sûr fait de lettres, de chiffres, du tiret et du tiret bas ; les caractères + et / du Base64 classique ont un sens particulier dans une adresse web, ils cèdent donc la place à - et _, tandis que le remplissage final en = n'est même pas écrit. Les trois parties d'un JWT utilisent cet encodage — c'est pourquoi un token traverse intact une barre d'adresse, un cookie ou un en-tête HTTP. Encoder n'est pas chiffrer : n'importe quel outil fait le chemin inverse sans clé, et cette page ne fait rien d'autre.

Quelle est la différence entre décoder et vérifier un JWT ?

Décoder, c'est défaire l'encodage Base64URL et lire ce que disent l'en-tête et le payload ; aucune clé n'est nécessaire, tout le monde peut le faire, et c'est ce que fait cet outil. Vérifier, c'est calculer si la signature, le contenu et la clé secrète concordent : changez un seul caractère du contenu, ou signez avec une autre clé, et la vérification échoue. La différence est critique pour la sécurité — un token décodé dit seulement ce qui est affirmé, un token vérifié prouve que l'affirmation a été signée par le détenteur de la clé. Côté serveur, décoder ne suffit jamais ; la signature se vérifie à chaque requête.

Ne vous fiez pas au contenu décodé : la signature n'a pas été vérifiée

Les deux premières parties d'un JWT ne sont pas chiffrées, seulement encodées en Base64URL ; cet encodage est une enveloppe, pas un verrou, et n'importe qui peut l'ouvrir. La confiance vient de la troisième partie, la signature — un condensé mathématique du contenu et d'une clé secrète, que seule une partie détenant la clé peut vérifier.

Cet outil saute la vérification exprès : la faire ici supposerait de coller votre clé secrète dans une page web, et une clé de production ne se colle dans aucun site, celui-ci compris. Ce que vous voyez répond à la question « qu'affirme ce token » ; à la question « ce token est-il authentique », seul votre serveur peut répondre, en confrontant la signature à la clé.

Que signifient les champs du payload ?

La RFC 7519 normalise une poignée de noms de champs ; le reste dépend de l'application. Voici ceux que vous rencontrerez le plus souvent :

• sub → le titulaire du token (le plus souvent l'identifiant utilisateur)
• iss → le système qui a émis le token (issuer)
• aud → le système auquel le token est destiné (audience)
• exp → l'instant d'expiration ; passé ce moment, le serveur rejette le token
• iat → l'instant d'émission ; l'écart avec exp donne la durée de vie
• nbf → invalide avant cet instant (tokens postdatés)

Questions fréquentes

Comment décoder un JWT ?

Collez le token dans le panneau de gauche — c'est tout. L'en-tête et le payload s'ouvrent aussitôt en JSON formaté, et les champs de temps comme exp et iat sont convertis en dates lisibles. Aucune installation, aucune clé nécessaire.

Mon token est-il envoyé à un serveur ?

Non. Le décodage tourne entièrement dans votre navigateur et le token n'est transmis nulle part. Restez prudent malgré tout : un token de production encore valide ouvre une session à quiconque le détient — fermez la page une fois le travail fini.

Cet outil vérifie-t-il la signature ?

Non, et c'est voulu. La vérification exige la clé secrète, et une clé secrète ne doit jamais être collée dans une page de navigateur. L'outil montre seulement le contenu ; que le token ait bien été émis par votre serveur, seul votre serveur peut le confirmer.

Comment savoir si le token a expiré ?

Si le payload porte un champ exp, l'outil le convertit en date et indique à côté si l'échéance est passée ou non. La comparaison utilise l'horloge de votre ordinateur — si elle est fausse, le verdict l'est aussi.