Comment décoder un JWT

Collez le jeton dans un décodeur qui s’exécute dans votre navigateur, jamais dans un qui demande un envoi ; lisez l’en-tête et le payload, confrontez exp à l’heure actuelle et traitez alg:none comme une alarme. Décoder, c’est lire, pas vérifier — seule la clé de l’émetteur prouve qu’un jeton est authentique. Chaque étape ci-dessous se passe localement, dans le décodeur JWT du site.

100 % local

Vous voulez juste l’outil ? Ouvrez Décoder un JWTLit un JSON Web Token et explique chaque champOuvrir l’outil

Un JSON Web Token ressemble à du papier peint — trois segments base64 reliés par des points — et ce déguisement est précisément la raison pour laquelle le décoder méthodiquement, plutôt que de plisser les yeux dessus, mérite une procédure. Il contient un en-tête qui nomme l’algorithme de signature, un payload qui dit à qui appartient le jeton et quand il meurt, et une signature qui (si elle est authentique) lie les deux à celui qui l’a émis. Les deux premiers sont lisibles par tout le monde ; le troisième ne se vérifie qu’avec une clé.

Cette page est la version sûre de ce travail de lecture : cinq étapes, chacune avec une vérification, toutes exécutées dans votre propre navigateur. La distinction compte parce qu’un JWT est un jeton porteur — quiconque le détient peut s’en servir. Coller un jeton vivant dans une page web quelconque qui le décode côté serveur, c’est remettre ce secret au propriétaire de la page ; le coller dans un outil qui décode localement, c’est ne le remettre à personne, et le panneau Network permet de vérifier cette affirmation au lieu de la croire sur parole.

Une attente à poser avant la première étape : un décodeur peut vous dire ce que dit un jeton et signaler ce qui cloche, mais il ne peut pas vous dire qu’un jeton est authentique. L’authenticité est une affaire de signature, et les questions de signature exigent la clé de l’émetteur. La dernière étape porte sur le lieu où cette vérification se produit réellement — et sur les raisons pour lesquelles la réponse n’est généralement pas cette page.

Les cinq étapes s’exécutent dans le décodeur JWT du site — collez, lisez, et chaque claim arrive avec son explication.

Pour l’anatomie complète des trois segments, le guide de la structure JWT explique chaque partie avec de vrais exemples, avant que vous n’inspectiez un jeton en conditions réelles.

Les étapes

Copiez uniquement le jeton — rien avant, rien après
Depuis l’en-tête de réponse, l’entrée localStorage ou la requête que vous inspectez, copiez exactement les trois segments base64 : le morceau qui commence par eyJ et s’arrête au dernier caractère du troisième segment séparé par des points. Retirez tout préfixe Bearer, les guillemets et les espaces — un décodeur peut en tolérer une partie, mais coller un jeton propre rend chaque contrôle en aval sans ambiguïté.
Vérifiez : Ce que vous avez copié commence par eyJ (le base64 de {" — le cas de tout en-tête JWT) et ne contient aucune espace. Ce minuscule contrôle attrape l’échec de collage le plus courant avant même qu’un outil n’intervienne.
Collez-le dans un décodeur qui s’exécute localement
Ouvrez le décodeur JWT et collez. L’en-tête et le payload se décodent instantanément, dans l’onglet — pas d’envoi, et le panneau Network n’affichera aucune requête transportant le jeton. C’est ici que se séparent les versions sûre et risquée de cette procédure : un décodeur côté serveur a vu votre jeton ; un décodeur local, non, car il ne quitte jamais votre machine.
Vérifiez : Deux objets JSON apparaissent — l’en-tête d’abord, le payload dessous — sans erreur entre eux. Si le décodeur signale un base64 invalide ou un JSON cassé, le jeton a été tronqué ou abîmé à la copie ; recopiez-le depuis la source.
Lisez l’en-tête — l’algorithme fixe le modèle de menace
L’alg de l’en-tête nomme la façon dont le jeton a été signé : HS256 signifie un secret partagé, RS256 ou ES256 une paire de clés dont seul l’émetteur détient la moitié privée, none signifie non signé. L’outil signale alg:none bruyamment, car un jeton non signé est une affirmation que n’importe qui aurait pu écrire — en accepter un n’est pas une erreur, c’est un échec de politique. Notez l’alg maintenant ; la cinquième étape en aura besoin.
Vérifiez : La ligne alg montre un vrai algorithme (HS256, RS256, ES256 sont les trois courants) et jamais none. Si elle affiche none, arrêtez-vous : le jeton ne prouve rien sur lui-même, et celui qui l’a émis doit l’apprendre.
Lisez le payload — et confrontez exp à l’heure réelle
Les claims du payload sont toute l’histoire du jeton : sub nomme à qui il appartient, iss nomme qui l’a fabriqué, aud nomme qui peut l’accepter, et exp est le moment de sa mort — décodé en vraie date et heure par l’outil, et non le 1735689600 que vous devriez convertir vous-même. L’outil soulève aussi des avertissements : un jeton expiré, un sans exp du tout, un dont le nbf se situe dans le futur parce que l’horloge de l’émetteur avance.
Vérifiez : La ligne exp montre une date sur laquelle on peut raisonner — « expiré il y a 4 heures » ou « expire dans 11 minutes » — et la liste d’avertissements correspond à ce que vous voyez. Un jeton sans exp mérite la méfiance : sur le papier, il n’expire jamais.
Vérifiez auprès de l’émetteur — pas avec le décodeur
Décoder ne prouve rien de l’authenticité : le segment de signature ne se contrôle que contre une clé, et la clé appartient à l’émetteur. En pratique, la vérification se produit là où vit la clé — votre backend, une passerelle API, la bibliothèque de votre fournisseur d’identité — pas dans un onglet de navigateur. Si vous déboguez les raisons pour lesquelles un service a rejeté un jeton, apportez-lui les claims décodés : un exp déjà dépassé, un aud qui ne correspond pas, ou un kid que le cache de clés n’a pas encore récupéré expliquent la plupart des rejets.
Vérifiez : Vous savez nommer, pour le jeton devant vous, qui doit le vérifier (le service qui l’a accepté) et ce que ce service contrôle (la signature contre la clé de l’émetteur, plus exp, nbf et aud). Si vous ne le savez pas, le guide de la structure JWT contient la pièce manquante.

Décoder et vérifier sont deux verbes différents

Décoder, c’est du base64 et du parsage JSON — de la lecture. Vérifier, c’est une opération cryptographique — confronter la signature à une clé que seul l’émetteur détient. Un décodeur qui vous afficherait un badge vert « valide » mentirait, car il ne peut jamais détenir la clé privée de l’émetteur, et même pour les algorithmes à clé publique, le contrôle revient au service qui accepte le jeton, celui qui sait quelle clé et quelle audience s’appliquent.

Voilà pourquoi l’outil ne revendique jamais la validité et explique à la place ce qu’il voit : l’algorithme, les claims, l’expiration sous forme de date, et les avertissements qu’un lecteur attentif soulèverait. Le lecteur qui a besoin d’un verdict — l’API qui reçoit le jeton — est la seule partie à avoir les éléments pour en donner un.

Les claims à lire à chaque fois

Quatre claims enregistrés portent l’essentiel de l’histoire. exp : quand le jeton meurt — la ligne la plus utile de la page. sub : de qui parle le jeton, en général un identifiant d’utilisateur ou de service. iss et aud : qui l’a émis et qui peut l’accepter — un jeton émis pour une API est souvent rejeté par une autre, et le côté qui refuse ne dysfonctionne pas : il lit correctement aud.

Les claims personnalisés (rôles, scopes, identifiants de tenant) côtoient les autres et se décodent de la même façon, mais traitez-les comme des claims, pas comme des faits : ils ne valent que par la signature qui les soutient, et le décodeur ne l’a pas vérifiée. iat (issued at) et nbf (not before) complètent les claims de chronologie et expliquent la classe d’erreurs « jeton pas encore valide », presque toujours due à un décalage d’horloges.

Ce qu’un décodeur peut signaler — et ce que seul le serveur peut savoir

La couche d’avertissements attrape ce que le payload avoue à visage découvert : alg:none, un segment de signature vide, un exp dans le passé, un jeton sans aucun exp, un nbf dans le futur. Ce sont les défauts visibles sans aucune clé, et ils méritent d’être lus même quand le jeton « fonctionne » — un système qui accepte un jeton expiré est un système que vous voulez connaître.

Ce qu’aucun outil de navigateur ne peut vous dire : si la signature se vérifie réellement, si l’émetteur reconnaît toujours cette session, si le jeton a été révoqué. Ces réponses vivent derrière la clé de l’émetteur et ses registres. L’honnêteté du décodeur, c’est la frontière qu’il trace entre lire un jeton et lui faire confiance.

Où se cachent les jetons — et pourquoi cela plaide pour le décodage local

Les JWT se logent dans les en-têtes Authorization, le localStorage du navigateur, les fragments d’URL après les redirections de connexion et les journaux applicatifs — des endroits copiés bien plus négligemment que les fichiers. Chacune de ces copies demeure un secret vivant jusqu’à son expiration, et c’est pourquoi l’étape de décodage de cette procédure exige un outil local : captures d’écran, tickets et messages de chat contenant des payload décodés sont lisibles par tous, mais le jeton brut, lui, ne devrait voyager nulle part excepté vers les services censés le vérifier.

Les habitudes pratiques en découlent : décodez localement, caviardez avant de partager (le payload d’une capture d’écran suffit en général à déboguer), et quand un jeton doit circuler pour un débogage, faites-le passer par le canal que l’émetteur jugerait acceptable — pas un site de paste public.

Questions fréquentes

Est-il sûr de coller mon JWT dans ce décodeur ?

Oui, parce que le décodage se fait dans votre navigateur — le jeton est parsé par du code local et n’est jamais transmis nulle part. Vous n’avez pas à le croire sur parole : ouvrez les DevTools, ouvrez le panneau Network, collez un jeton et constatez qu’aucune requête ne le transporte. La Content-Security-Policy du site interdit les connexions sortantes par construction, donc même un bug ne pourrait pas l’exfiltrer.

Le décodage peut-il me dire si un jeton est valide ?

Non, et un décodeur qui le prétend vous induit en erreur. La validité est une question de signature — le jeton doit être contrôlé contre la clé de l’émetteur, plus les politiques exp, nbf et aud du service qui le reçoit. Un décodeur vous montre ce que dit le jeton et signale les défauts de surface (expiré, non signé, exp absent) ; le verdict appartient au vérificateur qui détient la clé.

Que signifie alg:none et pourquoi est-ce dangereux ?

Cela signifie que l’en-tête ne déclare aucun algorithme de signature — le segment de signature devrait être vide, et le contenu du jeton est une affirmation que n’importe qui aurait pu écrire. Des algorithmes comme HS256 existent précisément pour que la falsification soit détectable ; alg:none retire cette garantie. Un décodeur le signale bruyamment parce qu’accepter un tel jeton est une classe de vulnérabilité connue, pas une bizarrerie de formatage.

Pourquoi mon jeton apparaît-il comme expiré alors que l’application fonctionne encore ?

Parce que l’application l’a rafraîchi. Les jetons d’accès à durée courte expirent exprès et sont échangés contre des neufs en coulisses, généralement via un refresh token ; ce que vous avez copié était sans doute déjà une génération retirée. Décodez le jeton que l’application envoie maintenant : son exp devrait être dans le futur — si ce n’est pas le cas, le service qui l’accepte ne vérifie pas l’expiration, ce qui vaut la peine d’être su.

Dans quelle unité sont mesurés exp, iat et nbf ?

En secondes depuis le 1er janvier 1970 UTC — le temps Unix — c’est pourquoi un payload brut les montre comme des nombres à dix chiffres tels que 1735689600. Le décodeur convertit chacun en une vraie date et heure et exprime la relation au présent (« expiré il y a 4 heures », « expire dans 11 minutes »), la seule forme sur laquelle un humain puisse réellement agir.

Puis-je partager une capture d’écran d’un jeton décodé ?

L’en-tête et le payload décodés sont généralement sans problème — ils sont lisibles par conception, et une capture d’écran montrant les claims, c’est ainsi que se déroule la plupart du débogage. Ce qui ne doit jamais être partagé, c’est le jeton brut lui-même : c’est un jeton porteur, et quiconque le détient peut l’utiliser jusqu’à ce qu’il expire. Caviardez les segments de signature et tout identifiant que vous ne mettriez pas dans un ticket, et tenez le jeton complet entièrement à l’écart des captures d’écran.

Équipe ToolsByUs · Comment nous vérifions nos outils