Décodeur et encodeur JWT — décoder, vérifier et signer des JSON Web Tokens

Décodez l’en-tête et la charge utile d’un JWT, lisez l’expiration en clair, vérifiez les signatures HS, RS, PS et ES ou signez un nouveau jeton. Rien ne quitte votre navigateur.

Jeton

En-tête

{
  "alg": "HS256",
  "typ": "JWT"
}

Charge utile

{
  "sub": "user_42",
  "name": "Ada Lovelace",
  "role": "admin",
  "iat": 1757320000,
  "exp": 1788856000
}

Claims

sub	Sujet	user_42
name		Ada Lovelace
role		admin
iat	Émis le	1757320000
exp	Expiration	1788856000

Vérifier la signature (HS256)Le secret est encodé en Base64 / Base64URL

Le jeton d’exemple est signé avec le secret demo-secret-do-not-use.

Le décodage ne vérifie jamais la signature : n’importe qui peut lire un JWT, seule la signature prouve qui l’a émis. Les jetons HS* nécessitent le secret partagé ; RS*, PS*, ES* et EdDSA nécessitent la clé publique de l’émetteur (PEM, certificat, JWK, ou le JWKS de son /.well-known/jwks.json, associé par kid). Ne collez pas de secrets de production ni de clés privées dans une page web, y compris celle-ci ; utilisez des clés de test.

Les jetons et les clés sont traités dans votre navigateur avec WebCrypto et ne sont jamais envoyés ; considérez tout de même un jeton ou une clé de production collés comme des identifiants. Parcourir tous les outils gratuits.

Un problème, ou quelque chose à améliorer ? Nous lisons chaque message et corrigeons vite.

Ce décodeur JWT gratuit affiche l’en-tête, la charge utile et les claims d’un JSON Web Token, transforme exp, iat et nbf en dates lisibles avec un verdict clair valide ou expiré, vérifie la signature (HMAC avec un secret, ou RSA, RSA-PSS, ECDSA et Ed25519 avec une clé publique, un certificat ou une JWK) et propose un encodeur qui signe de nouveaux jetons pour vos tests. Tout se passe dans votre navigateur, ce qui compte ici plus que pour la plupart des outils : un jeton collé est souvent un identifiant actif, et il ne doit être envoyé au serveur de personne, le nôtre compris.

Un JWT se compose de trois sections Base64URL séparées par des points : un en-tête qui nomme l’algorithme, une charge utile de claims et une signature. Les deux premières ne sont pas chiffrées, seulement encodées : tout le monde peut les lire. C’est la signature qui prouve qui a émis le jeton et qu’il n’a pas été modifié. Décoder n’est donc pas la même chose que faire confiance, et la page garde cette distinction visible.

Mode d’emploi

Collez le jeton. Un « Bearer » initial issu d’un en-tête Authorization ne pose pas de problème : il est retiré.
Lisez la ligne d’état : valide pour combien de temps, expiré depuis quand, ou pas encore valide.
Vérifiez la charge utile et le tableau des claims. Les claims de date sont affichés en dates locales à côté des secondes Unix brutes.
Pour vérifier, saisissez la clé puis appuyez sur Vérifier : le secret partagé pour HS256/384/512, ou, pour les jetons RS, PS, ES et EdDSA, la clé publique de l’émetteur en PEM, certificat, JWK ou JWKS complet (la clé est choisie d’après le kid du jeton).
Pour créer un jeton, passez à Encoder et signer, choisissez l’algorithme, modifiez le JSON de l’en-tête et de la charge utile, et saisissez un secret ou collez une clé privée PKCS#8 (ou générez une paire de clés de test). Signez, puis ouvrez le jeton dans le décodeur pour le vérifier.
Copiez la charge utile ou l’en-tête en JSON formaté si vous en avez besoin dans un rapport de bug ou un jeu de test.

Questions fréquentes

Puis-je coller un vrai jeton ici sans risque ?

Le jeton est décodé en JavaScript dans votre navigateur et n’est jamais transmis ; vous pouvez vous déconnecter d’Internet et la page continue de fonctionner. Cela dit, traitez un jeton de production comme un mot de passe : ne le collez pas dans une page en laquelle vous n’avez pas confiance, et préférez un jeton de test à courte durée de vie quand c’est possible.

Pourquoi puis-je lire la charge utile sans le secret ?

Parce que les JWT sont signés, pas chiffrés. La charge utile est du JSON encodé en Base64URL que tout le monde peut décoder. Le secret (ou la clé privée) n’est nécessaire que pour créer ou vérifier la signature. Ne mettez jamais de données sensibles dans la charge utile d’un JWT, sauf si vous utilisez JWE, la variante chiffrée, que cet outil ne décode pas.

Que signifient exp, iat et nbf ?

Ce sont des horodatages Unix en secondes. exp indique quand le jeton expire ; iat, quand il a été émis ; nbf (not before), le premier instant où il est valide. Un vérificateur doit rejeter un jeton après exp ou avant nbf. La ligne d’état applique ici ces deux règles à l’heure actuelle.

Comment vérifier un jeton RS256 ou ES256 ?

Il vous faut la clé publique de l’émetteur, jamais la clé privée. Les fournisseurs d’identité la publient sous forme de JWKS à une URL comme https://issuer/.well-known/jwks.json (Auth0, Okta, Cognito, Azure AD et Google le font tous). Collez le JWKS complet et la clé dont le kid correspond à l’en-tête du jeton est utilisée, ou collez une seule JWK, une clé publique PEM (BEGIN PUBLIC KEY) ou un certificat X.509. La page ne télécharge rien elle-même : copiez le JWKS depuis votre navigateur.

Puis-je créer et signer un JWT ici ?

Oui. Encoder et signer prend le JSON de l’en-tête et de la charge utile et signe avec HS256/384/512 et un secret, ou avec RS, PS, ES ou EdDSA et une clé privée au format PEM PKCS#8 (BEGIN PRIVATE KEY). Les anciens fichiers BEGIN RSA PRIVATE KEY sont au format PKCS#1 ; convertissez-les avec openssl pkcs8 -topk8 -nocrypt -in key.pem. N’utilisez que des clés de test : une clé de signature de production collée dans une page web, quelle qu’elle soit, doit être considérée comme compromise.

Que signifie « alg: none » et pourquoi cet avertissement ?

Cela déclare que le jeton n’a pas de signature. Certaines bibliothèques ont autrefois accepté ces jetons comme valides, ce qui permettait à des attaquants de forger n’importe quelle charge utile. Un vérificateur correctement configuré rejette d’office alg none. Si vous le voyez dans un système réel, c’est une faille de sécurité, pas une curiosité.

Anatomie d’un JWT

En-tête : {"alg":"HS256","typ":"JWT"} indique au vérificateur quel algorithme a signé le jeton. Charge utile : les claims, un objet JSON contenant ce que l’émetteur a choisi d’inclure, plus les claims enregistrés (iss, sub, aud, exp, nbf, iat, jti) que les vérificateurs comprennent. Signature : HMAC ou signature numérique calculée sur base64url(header).base64url(payload). Modifiez un seul caractère de la charge utile et la signature ne correspond plus : c’est tout le principe.

Erreurs courantes avec les JWT

• Faire confiance à la charge utile sans vérifier la signature, ou vérifier avec l’algorithme indiqué dans le jeton plutôt qu’avec celui qu’attend le serveur (confusion d’algorithme).

• Des jetons d’accès à longue durée de vie. Gardez un exp court (de quelques minutes à une heure) et utilisez un jeton de rafraîchissement pour les sessions plus longues.

• Mettre des données personnelles ou secrètes dans la charge utile ; elle est lisible par quiconque détient le jeton.

• Stocker les jetons dans localStorage sur un site exposé à la moindre faille XSS. Un cookie httpOnly est plus sûr pour les sessions dans le navigateur.

• Oublier de vérifier aud et iss, ce qui permet de rejouer contre un service un jeton émis pour un autre.

• Des secrets HMAC trop courts ou choisis par un humain. HS256 exige au moins 256 bits (32 octets aléatoires) ; un secret devinable peut être cassé par force brute hors ligne à partir d’un seul jeton.

Quel algorithme de signature choisir

• HS256 (HMAC-SHA256) : un seul secret partagé signe et vérifie. Simple et rapide, mais chaque service qui vérifie peut aussi émettre des jetons. Convient au sein d’un même backend.

• RS256 (RSA PKCS#1 v1.5 avec SHA-256) : l’option asymétrique la plus largement prise en charge ; l’émetteur garde la clé privée, tous les autres vérifient avec la clé publique. Les signatures font 256 octets avec une clé de 2048 bits.

• PS256 (RSA-PSS) : mêmes clés que RS256 avec un schéma de remplissage plus moderne ; à utiliser quand tous les consommateurs le prennent en charge.

• ES256 (ECDSA P-256) : des clés bien plus petites et des signatures de 64 octets pour une sécurité comparable ; courant dans les systèmes récents et exigé par certains (Apple, API proches de WebAuthn).

• EdDSA (Ed25519) : signatures rapides et déterministes, de mieux en mieux prises en charge par les bibliothèques ; la prise en charge par les navigateurs est arrivée plus tard que pour les autres.

Outils gratuits similaires

Encodeur / décodeur Base64 — Encodez du texte ou des fichiers en Base64, transformez des images en data URI avec extraits CSS et <img>, et décodez du Base64 en fichier avec aperçu. Rien ne quitte votre navigateur.
Formateur JSON — Indentez, minifiez et validez du JSON, avec les erreurs d’analyse localisées par ligne et colonne. Dans votre navigateur, sans envoi.
Générateur de mots de passe — Générez un mot de passe aléatoire fort, une phrase de passe facile à retenir ou un code PIN. Tout se passe dans votre navigateur, rien n’est envoyé ni stocké.