Outils gratuits pour développeurs

Décodeur & débogueur JWT.

Décodez un token, modifiez l'en-tête et la charge utile avec resignature en direct, et vérifiez les signatures — sans que le token ne quitte jamais votre navigateur.

Conçu et hébergé dans l'Union européenne
Débogueur JWT
Décoder · modifier · vérifier
Fonctionne entièrement dans votre navigateur
En-tête Charge utile Signature

Signature

Collez un token pour inspecter et vérifier sa signature.

Le décodage, la signature et la vérification s'exécutent entièrement dans votre navigateur — rien n'est transmis ni stocké. Malgré tout : traitez les JWT de production comme des mots de passe.

Qu'est-ce qu'un JWT ?

Un JSON Web Token (RFC 7519) est un moyen compact et autonome de transmettre des claims entre parties — le plus souvent, la preuve de l'identité d'un utilisateur et de ses droits. Comme le token est signé, une API peut faire confiance à son contenu sans requête en base de données, ce qui fait des JWT l'épine dorsale de l'authentification sans état, d'OAuth 2.0 et d'OpenID Connect.

Trois parties, séparées par un point

  • En-tête — métadonnées : l'algorithme de signature (alg) et le type de token.
  • Charge utile — les claims : les claims enregistrés comme exp et sub, plus tout ce que l'émetteur ajoute.
  • Signature — un MAC ou une signature numérique sur les deux premières parties, prouvant l'intégrité et l'origine.

Chaque partie est encodée en Base64URL — encodée, pas chiffrée. N'importe qui peut lire le contenu d'un JWT ; seule la signature est protégée.

Décoder n'est pas vérifier

L'erreur JWT la plus courante : considérer une charge utile décodée comme fiable. Le décodage ne nécessite aucune clé — un attaquant peut fabriquer n'importe quelle charge utile. La confiance ne vient que de la vérification de la signature avec votre secret (HS256) ou la clé publique de l'émetteur (RS256/ES256), et de la vérification de exp, iss et aud. Les bibliothèques côté serveur le font pour vous — configurez une liste blanche explicite d'algorithmes autorisés.

Gardez vos tokens en sécurité

  • Ne mettez jamais de secrets ni de données personnelles dans la charge utile — elle est lisible par tout le monde.
  • Gardez une durée de vie courte pour les tokens d'accès et renouvelez-les avec des tokens de rafraîchissement.
  • Transmettez les tokens uniquement via HTTPS et stockez-les hors de portée des scripts injectés.
  • Rejetez alg: none et vérifiez avec une liste blanche d'algorithmes autorisés.

Questions fréquentes

Est-il sûr de coller un JWT dans un décodeur en ligne ?
Ce débogueur s'exécute entièrement dans votre navigateur — votre token n'est jamais transmis, stocké ni journalisé, ce que vous pouvez vérifier dans l'onglet réseau de vos outils de développement. Malgré tout, traitez les tokens de production comme des mots de passe : un JWT donne souvent accès à un compte ou à une API. Privilégiez des tokens de test dès que possible, ici comme dans tout autre outil.
Quelle est la différence entre décoder et vérifier un JWT ?
Le décodage se contente de lire le token : l'en-tête et la charge utile sont encodés en Base64URL, pas chiffrés, donc n'importe qui peut les décoder. La vérification contrôle la signature cryptographique avec un secret ou une clé publique, prouvant que le token a été émis par la partie attendue et n'a pas été altéré. Ne faites jamais confiance aux claims d'un token sans vérifier sa signature.
Puis-je modifier un token et obtenir une signature valide ?
Oui — pour les algorithmes HMAC (HS256/384/512), saisissez le secret partagé et le débogueur resigne le token automatiquement à chaque modification de l'en-tête ou de la charge utile. Pour les algorithmes asymétriques comme RS256, la signature nécessite la clé privée, que vous ne devriez jamais coller dans un site web — les modifications laissent donc l'ancienne signature en place, et elle est signalée comme invalide.
Puis-je décoder un JWT sans connaître la clé secrète ?
Oui — le décodage ne nécessite aucune clé, car l'en-tête et la charge utile sont seulement encodés en Base64URL. Le secret ou la clé privée n'est nécessaire que pour créer une signature valide, et le secret ou la clé publique pour en vérifier une.
Quels sont les claims standard d'un JWT ?
La RFC 7519 définit sept claims enregistrés : iss (issuer), sub (subject), aud (audience), exp (date d'expiration), nbf (pas valide avant), iat (émis le) et jti (identifiant unique du token). Tous sont facultatifs, et les applications ajoutent leurs propres claims personnalisés — rôles, e-mail, scopes.
Pourquoi mon token est-il marqué comme expiré ?
Le claim exp contient un timestamp Unix (en secondes) ; une fois cet instant passé, le token doit être rejeté. Les tokens expirés sont normaux — les tokens d'accès ne sont souvent valides que quelques minutes. Votre application devrait obtenir un nouveau token, généralement via un token de rafraîchissement, plutôt que de prolonger l'ancien.
Quelle est la différence entre HS256 et RS256 ?
HS256 est symétrique : le même secret signe et vérifie, si bien que tout service qui vérifie pourrait aussi forger des tokens. RS256 est asymétrique : une clé privée signe, une clé publique partageable vérifie. Utilisez RS256 (ou ES256) dès que les tokens franchissent les frontières entre services ; HS256 convient lorsque le même service les émet et les consomme.
Que signifie alg: none, et pourquoi est-ce dangereux ?
Un JWT non sécurisé n'a aucune signature. Si un serveur accepte naïvement alg: none, un attaquant peut forger des tokens arbitraires. Les bibliothèques devraient être configurées avec une liste blanche explicite d'algorithmes ; ce débogueur signale de tels tokens par un avertissement.
Cet outil peut-il décoder des JWT chiffrés (JWE) ?
Non. Les tokens JWE (cinq segments Base64URL au lieu de trois) sont réellement chiffrés, et leur lecture nécessite la clé de déchiffrement. Cet outil traite les tokens JWS, bien plus courants — la variété signée à trois segments.

Des outils gratuits par une entreprise de logiciels européenne.

  • Fonctionne dans votre navigateur
  • Conçu & hébergé dans l'UE
  • Aucun compte requis