Décoder un JWT — Lire En-tête et Payload
Décodez un JWT pour lire clairement son en-tête et sa charge utile, instantanément et en privé.
Le jeton reste sur votre appareil
Rien à supprimer ensuite
Conçu pour des identifiants actifs
Fonctionne dans tout navigateur moderne
Comment ça marche
- 1
Collez le jeton
En entier, points compris : les trois parties sont séparées par eux.
- 2
Lisez les revendications
En-tête d’un côté, charge de l’autre, horodatages convertis en dates.
- 3
Vérifiez ce que vous cherchiez
Le plus souvent l’expiration, l’émetteur, l’audience ou l’utilisateur auquel le jeton se rapporte.
Pourquoi cet outil
En-tête et charge côte à côte
L’algorithme et l’indice de clé près des revendications : c’est là que se règlent la plupart des questions de débogage.
Horodatages lisibles
`exp`, `iat` et `nbf` affichés en dates plutôt qu’en nombres à dix chiffres à convertir soi-même.
Expiration comparée à maintenant
Vous voyez tout de suite si le jeton est encore dans sa fenêtre, sans faire le calcul.
Honnête sur la vérification
Cet outil décode ; il ne vérifie pas de signature, et il le dit au lieu de laisser croire que le jeton est valide.
Rien n’est transmis
Le jeton est analysé dans votre navigateur — un identifiant de session actif n’atteint jamais un serveur.
Gratuit et sans compte
Aucune inscription, aucun filigrane et aucune limite sur le nombre de jetons inspectés.
Décoder n’est pas vérifier, et l’écart constitue tout le modèle de sécurité
Un JWT compte trois parties séparées par des points, et les deux premières ne sont que du texte base64url. Quiconque détient le jeton peut lire l’en-tête et la charge en une étape — c’est ce que fait cette page — sans clé, sans autorisation et sans secret. La vérification est une opération entièrement distincte : recalculer la signature sur les deux premières parties avec la clé de l’émetteur et contrôler qu’elle correspond à la troisième. Seule la vérification établit que le jeton est authentique et non modifié. Un décodeur vous dit ce qu’un jeton prétend, jamais si la prétention est vraie, car n’importe qui peut fabriquer un jeton disant ce qu’il veut. Si vous déboguez, décoder répond à votre question. Si vous décidez d’accorder ou non votre confiance à une requête, décoder ne répond à rien du tout.
La charge est lisible par tous, et on l’oublie sans cesse
Cela découle du point précédent et mérite d’être dit à part, car c’est une source réelle d’exposition de données. La charge d’un JWT est encodée, pas chiffrée. Chaque revendication qu’elle contient — identifiant d’utilisateur, adresse e-mail, rôle, locataire, tout champ interne qu’il paraissait commode d’ajouter — est visible pour quiconque possède le jeton, y compris le navigateur auquel il a été délivré, toute extension qui y tourne et quiconque le récupérera ensuite. La signature protège la charge d’être modifiée, non d’être lue. Un jeton est donc un endroit raisonnable pour un identifiant et un rôle, et un mauvais endroit pour une adresse, un numéro de téléphone, un statut de licence que quelqu’un jugerait gênant, ou tout ce que vous n’imprimeriez pas au dos d’une enveloppe. Si une revendication doit rester privée, sa place n’est pas dans le jeton.
Ne laissez jamais le jeton vous dire comment le vérifier
Les vulnérabilités JWT les plus célèbres partagent une même forme : une bibliothèque lit le champ `alg` de l’en-tête et lui fait confiance. La version historique est `alg: none`, qui déclare le jeton non signé — un vérificateur qui l’honore accepte n’importe quoi, et l’attaquant écrit simplement sa propre charge puis retire la signature. La version plus subtile est la confusion d’algorithmes : un jeton signé en HMAC est présenté à un serveur qui attend du RSA ; si le code passe la clé publique RSA comme secret HMAC et que cette clé est publiée, l’attaquant peut signer des jetons avec elle. Les deux se corrigent de la même façon : le code qui vérifie décide de l’algorithme et de la clé qu’il accepte et rejette tout le reste, au lieu de lire la réponse dans la partie non fiable du jeton qu’il contrôle.
Les horodatages sont en secondes, et rien ne les fait respecter tout seul
Trois revendications définissent la fenêtre de validité. `exp` est l’expiration, `nbf` l’instant avant lequel le jeton ne doit pas être accepté, `iat` la date d’émission. Les trois sont en secondes depuis l’époque Unix, ce qui fait trébucher quiconque travaille dans un langage dont les horodatages natifs sont en millisecondes : le jeton obtenu est soit déjà expiré, soit valide pour les cinquante mille prochaines années, et ces deux erreurs sont assez fréquentes pour être vérifiées en premier. Plus important encore : ce sont des revendications, non une application. Rien dans le jeton ne cesse de fonctionner quand `exp` est passé ; l’expiration n’existe que si le code de vérification la compare à l’heure actuelle et rejette la requête. Un décodeur qui vous montre un jeton expiré indique l’intention de l’émetteur, non ce qu’un serveur donné en fera.
Un JWT ne peut pas être révoqué, et c’est le marché que vous avez accepté
La raison d’employer ces jetons est la vérification sans état : un serveur peut confirmer l’authenticité d’une requête avec une seule clé, sans consulter de base de données, ce qui leur permet de passer à l’échelle entre services. Conséquence directe : il n’y a rien à supprimer. Une session stockée en base s’achève dès que vous retirez la ligne ; un jeton signé reste valide jusqu’à son expiration quoi qu’il arrive chez l’émetteur, puisque personne ne le consulte. Un jeton fuité est donc exploitable jusqu’à échéance, et c’est précisément pourquoi les jetons d’accès doivent avoir une durée courte — des minutes, non des semaines — accompagnés d’un jeton de rafraîchissement plus durable, révocable parce qu’il est, lui, confronté à un stockage. Si vos jetons d’accès durent un mois, vous cumulez les inconvénients de l’absence d’état et aucune des protections d’une session.
Pourquoi c’est ici le cas le plus net pour décoder en local
Presque tous les autres outils de texte traitent une matière sensible par circonstance. Un JWT est sensible par définition : c’est l’identifiant lui-même, et un jeton valide non expiré suffit à agir en tant que l’utilisateur auquel il a été délivré. En coller un dans un décodeur hébergé envoie un identifiant d’authentification actif à un tiers, par un canal qui ne laisse aucune trace, en échange de la lecture de champs que vous pouviez lire en local. S’il reste des heures au jeton, celui qui le reçoit peut l’utiliser. Cette page analyse dans le navigateur et ne transmet rien, ce que vous pouvez vérifier dans l’onglet Réseau des outils de développement — et si vous avez déjà collé un jeton de production sur un site pour en lire l’expiration, considérer ce jeton comme compromis est la bonne réaction.
Erreurs courantes à éviter
- Prendre un décodage réussi pour un jeton valide. Décoder ne demande aucune clé et ne prouve rien ; seule la vérification de la signature avec la clé de l’émetteur établit l’authenticité.
- Mettre des données privées dans la charge. Elle est encodée, non chiffrée — la signature empêche de la modifier, pas de la lire, donc quiconque détient le jeton voit toutes les revendications.
- Laisser le jeton choisir son algorithme de vérification. Lire `alg` dans l’en-tête est le mécanisme des attaques `alg: none` et de confusion d’algorithmes ; le vérificateur doit fixer algorithme et clé à l’avance.
- Écrire `exp` en millisecondes. Les horodatages JWT sont en secondes depuis l’époque : une valeur en millisecondes donne un jeton valide des dizaines de milliers d’années, ou déjà expiré.
- Coller un jeton de production dans un décodeur hébergé. C’est un identifiant actif, le collage ne laisse aucune trace, et celui qui le reçoit peut s’en servir jusqu’à son expiration.
Comparaison
| Critère | Cet outil | Décodeurs en ligne | Un appel de bibliothèque |
|---|---|---|---|
| Jeton envoyé à un serveur | Jamais | Le plus souvent | Non |
| Horodatages affichés en dates | Oui | Parfois | Vous les formatez |
| Précise qu’il ne vérifie pas | Oui | Souvent flou | Explicite dans l’API |
| Fonctionne sans ouvrir de projet | Oui | Oui | Non |
| Compte ou inscription | Pas nécessaire | Souvent exigé | Pas nécessaire |
| Prix | Gratuit | Gratuit / offres payantes | Gratuit |
Fonctionnalités
Analyse complète des trois parties
En-tête, charge et segment de signature affichés séparément comme le format les définit.
base64url traité correctement
Les JWT emploient l’alphabet compatible URL sans remplissage, ce qu’un décodeur Base64 ordinaire rate.
Revendications standard nommées
`iss`, `sub`, `aud`, `exp`, `nbf`, `iat` et `jti` sont explicitées plutôt que laissées en abrégé.
Jetons malformés signalés
Un segment manquant ou un encodage invalide est signalé au lieu de produire un charabia partiel.
Unicode préservé dans les revendications
Noms et valeurs en arabe, en turc ou dans toute écriture se décodent intacts.
Instantané, sans requête
L’analyse a lieu au collage, rien n’est téléchargé et rien n’est envoyé.
Rien à installer
Pas de bibliothèque, pas d’environnement d’exécution, pas de dépendances : tout se passe sur la page web.
Compatible arabe et RTL
Interface complète en huit langues, dont l’arabe de droite à gauche.
Sécurisé par défaut
Servi en HTTPS, sans suivi du contenu ni envoi à un tiers.
Qui l’utilise
Développeurs
Comprendre pourquoi un appel d’API est rejeté — le plus souvent un jeton expiré ou la mauvaise audience.
Ingénieurs sécurité
Examiner les revendications et l’algorithme d’un jeton trouvé dans un journal ou un rapport de bogue.
Intégrateurs d’API
Confirmer quelles portées et quels rôles un fournisseur a réellement délivrés avant d’écrire du code.
Ingénieurs support
Lire un jeton fourni par un client pour voir à quel compte et à quel locataire il appartient.
Questions Fréquentes
Non. Tout s’exécute localement dans votre navigateur — votre texte n’est jamais envoyé, stocké ni partagé.
Oui — entièrement gratuit, sans compte et sans limite.