Aller au contenu principal
ToolsByUs

Décoder un JWT

Le décodeur JWT lit l’en-tête et la charge utile d’un JSON Web Token dans votre navigateur et explique ce qu’il a trouvé : l’algorithme de signature, chaque claim avec sa signification, et l’expiration décodée en une vraie date. Il ne vérifie jamais la signature, car cela exigerait d’envoyer votre token à quiconque détient la clé.

100 % local
JSON Web Token
0 B1 ligneLig. 1, Col. 1
Rien à décoder. Collez un jeton ci-dessus. Rien n’est envoyé : le décodage se fait dans cet onglet.

Comment fonctionne Décoder un JWT ?

Un JSON Web Token est trois segments encodés en base64url joints par des points : header.payload.signature. Les deux premiers sont des objets JSON, et ils ne sont pas chiffrés — base64url est un encodage, pas un chiffrement. Quiconque détient le token peut lire chaque claim qu’il contient, et c’est pourquoi mettre un mot de passe, un numéro de carte ou un identifiant de base de données interne dans la charge utile d’un JWT est une erreur que les gens commettent régulièrement et découvrent tard.

Le décodage est donc simple : couper sur les points, décoder en base64url les deux premiers segments, analyser chacun comme JSON. Le soin porte sur les détails qui cassent les décodeurs naïfs. Les segments JWT sont du base64url sans remplissage (RFC 7515 §2), si bien qu’un décodeur qui exige le remplissage = rejette la plupart des tokens réels. L’alphabet utilise - et _ plutôt que + et /, si bien qu’un décodeur Base64 standard échoue sur environ la moitié des tokens, selon ce que les octets aléatoires ont fini par encoder.

Ce que cet outil ajoute au-delà du décodage, c’est l’interprétation. Les claims enregistrés de la RFC 7519 sont annotés de leur signification. exp, nbf et iat sont des NumericDates — des secondes depuis l’époque Unix — donc ils sont affichés comme un horodatage réel et une durée relative, car « 1757546000 » n’est pas quelque chose sur quoi on peut agir, alors que « expiré depuis 4 heures » l’est.

Il cherche ensuite les problèmes spécifiques qui causent des incidents : un alg à none, un segment de signature vide, un token sans exp, un token pas encore valide parce que l’horloge de l’émetteur est en avance, un aud manquant qui permet de rejouer le token contre un autre service faisant confiance au même émetteur.

Il s’arrête délibérément avant la vérification. Vérifier une signature exige le secret ou la clé publique de l’émetteur, et la seule façon pour une page web d’en obtenir une est d’envoyer votre token quelque part. Offrir cela détruirait l’unique propriété qui rend sûr de coller un identifiant actif dans cette page.

Segment du token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  .eyJzdWIiOiJ1c3JfOGYyYTFiIiwiZXhwIjoxNzU3NTQ2MDAwfQ
  .3Zc0Kz1qHhVQ9oFmR2sT7xYbN4dJwEuLpAiCgXvKmO8

Décodé

header  { "alg": "HS256", "typ": "JWT" }
payload { "sub": "usr_8f2a1b", "exp": 1757546000 }

exp  2026-09-10 21:53:20 UTC  (expired)
sub  Subject — who the token is about

Quelles options et quels cas limites Décoder un JWT prend en charge ?

Référence technique et options
ParamètreTypeValeur par défautComportement et cas limites
algstringrequisAlgorithme de signature, dans l’en-tête. HS* est HMAC avec un secret partagé ; RS*/PS* sont RSA ; ES* est ECDSA ; EdDSA est Ed25519. Une valeur « none » est signalée comme une erreur : une bibliothèque qui fait confiance à l’alg provenant du jeton lui-même permet à n’importe qui de le contrefaire.
typ / kidstringoptionneltyp est conventionnellement « JWT ». kid identifie quelle clé a signé le jeton, et permet à un émetteur de faire tourner ses clés sans invalider tout d’un coup.
expNumericDateoptionnelSecondes depuis l’époque Unix, pas de millisecondes et pas de chaîne ISO. Ici décodé en un timestamp UTC et une heure relative. Un jeton sans n’expire jamais par lui-même et ne peut être arrêté que par révocation.
nbfNumericDateoptionnelNot-before (pas avant). Un jeton qui n’est pas encore valide est presque toujours dû à un décalage d’horloge entre le serveur émetteur et la machine qui le lit, plutôt qu’à un délai délibéré.
audstring | string[]optionnelDestinataire prévu. Un service doit rejeter un jeton dont le public n’est pas lui-même ; sans aud, un jeton créé pour un service peut être réutilisé contre un autre qui fait confiance au même émetteur.
Encodage du segmentbase64urlsans remplissageRFC 7515 §2 utilise l’alphabet URL-safe (- et _) sans remplissage. Les décodeurs Base64 standards échouent sur les jetons dont les octets produisent + ou /, c’est pourquoi un jeton se décode parfois dans un outil et pas dans un autre.
Signaturebase64urlnon vérifiéeAffichée mais jamais vérifiée. La vérification nécessite la clé de l’émetteur ; en obtenir une signifierait transmettre votre jeton. Un segment de signature vide est signalé, car cela signifie qu’il n’y a aucune protection de l’intégrité.
Taille d'entréebytes8 MBLa limite principale du thread, partagée sur tout le site. Les vrais jetons font quelques kilo-octets ; cette limite existe pour que coller le mauvais contenu ne puisse pas bloquer l’onglet.

Questions fréquentes

Est-il sûr de coller un vrai JWT dans cette page ?

Le décodage se fait entièrement dans votre navigateur et le token n’est jamais transmis — ouvrez DevTools, passez au panneau Réseau, collez un token, et vous ne verrez aucune requête le transportant. Cela rend cette page catégoriquement plus sûre qu’un décodeur qui envoie à un serveur, où votre token finit dans un journal d’accès. La réserve restante ne concerne pas ce site : tout identifiant que vous collez dans n’importe quel navigateur, sur une machine que vous ne contrôlez pas, devrait être renouvelé ensuite.

Pourquoi ne peut-il pas vérifier la signature ?

Parce que la vérification exige la clé. Pour HS256, c’est le secret partagé ; pour RS256, c’est la clé publique de l’émetteur, généralement récupérée depuis un endpoint JWKS. Une page de navigateur ne pourrait faire ni l’un ni l’autre sans envoyer votre token, ou le secret, quelque part — ce qui détruirait la propriété qui rend cette page sûre à utiliser. La vérification appartient à votre service, où la clé réside déjà.

Mon token se décode ici mais ma bibliothèque le rejette. Pourquoi ?

Décoder et accepter sont deux questions différentes. Les causes les plus fréquentes sont : le token a expiré (regardez la ligne exp — cet outil l’affiche comme une vraie date) ; l’audience ne correspond pas à ce que votre service attend ; le nbf est dans le futur parce que l’horloge du serveur émetteur est en avance ; ou la signature ne se vérifie pas avec la clé configurée dans votre service, souvent parce que l’émetteur a fait tourner ses clés et que le kid désigne désormais une clé que votre cache n’a pas encore récupérée.

Que signifie alg: none et pourquoi est-il signalé comme une erreur ?

Cela signifie que le token n’est pas signé. Le danger n’est pas la valeur elle-même mais ce qu’en fait un vérificateur : certaines bibliothèques JWT lisaient historiquement alg dans le token et choisissaient la méthode de vérification en conséquence, si bien qu’un attaquant pouvait prendre un token valide, changer l’algorithme en none, retirer la signature, et se le faire accepter. Un vérificateur correct décide de l’algorithme attendu à partir de sa propre configuration et ignore ce que le token prétend.

Un JWT est-il chiffré ?

Non. Un JWT standard (un JWS) est signé, pas chiffré — la signature prouve que la charge utile n’a pas été altérée, et ne fait rien pour la dissimuler. Chaque claim est lisible par quiconque détient le token, et c’est exactement ce que cette page démontre. Si vous devez cacher le contenu, il vous faut un JWE, qui a cinq segments plutôt que trois et ne peut pas être lu sans la clé de déchiffrement.

Puis-je décoder un token déjà expiré ?

Oui. L’expiration est un claim à l’intérieur de la charge utile, pas une propriété de l’encodage, donc un token expiré se décode exactement comme un token actif. Cet outil le lit et vous dit quand il a expiré et depuis combien de temps, ce qui est généralement le moyen le plus rapide de confirmer qu’un 401 intermittent est un problème de durée de vie de token plutôt qu’un problème de permissions.

Que peut faire d'autre Décoder un JWT ?

Équipe ToolsByUs · Comment nous vérifions nos outils