Encodage
JWT Encoder/Decoder
Encodage et décodage de tokens JWT — en-tête, payload, signature HMAC et champs standards.
Les exemples signés (tous sauf none) nécessitent HTTPS — la page est actuellement ouverte sans HTTPS.
Pour RS/PS/ES, la clé est générée automatiquement et temporairement — uniquement pour la démonstration, elle ne peut pas être réutilisée.
Les exemples signés (tous sauf none) nécessitent HTTPS — la page est actuellement ouverte sans HTTPS.
Claims
A JWT (JSON Web Token) is a compact format for transmitting signed data, made of three dot-separated parts: a header, a payload, and a signature. This tool decodes any JWT and shows all three parts, and can also build a new token signed with HMAC.
Decoding does not verify the signature — reading a token's contents needs no secret key. Verifying the signature only matters when you need to trust the token as genuine.
How to use it
- Decode: paste a JWT and the tool splits it into header, payload, and signature, highlighting standard claims like exp, iat, and sub.
- Encode: fill in the header and payload, provide a secret, and get a signed HMAC token (HS256/HS384/HS512) back.
- Check expiry: the exp claim is shown as a normal date, so you can immediately tell if a token has expired.
Common uses
- Debugging authentication issues by inspecting exactly what a request's token contains.
- Checking which claims (roles, permissions, expiry) your backend issues.
- Generating a test token for local development without running an auth server.
Things to keep in mind
A JWT is not encrypted, only Base64URL-encoded — anyone can read the payload. Never put passwords or other secrets in it.
The signature protects against tampering, not against being read. For confidentiality you need extra encryption (JWE) or an HTTPS transport.
Article sur cet outil: JWT : structure du token et ce que signifie « décoder » un JWT
Questions fréquentes
Décoder un JWT prouve-t-il qu'il est authentique ?
Non. Décoder un JWT révèle simplement le contenu de l'en-tête et du payload, encodés en Base64 et non chiffrés. Sans vérifier la signature avec la bonne clé secrète ou publique, rien ne garantit que le token n'a pas été modifié ou forgé.
Comment fonctionne la structure d'un JWT ?
Un JWT est composé de trois parties séparées par des points : l'en-tête (algorithme et type), le payload (les claims comme iss, sub, exp) et la signature, calculée à partir des deux premières parties et d'un secret ou d'une clé privée.
Mes tokens ou secrets sont-ils envoyés sur un serveur ?
Non, le décodage, l'encodage et la signature s'effectuent entièrement dans le navigateur. Aucun token ni secret n'est transmis à un serveur.
Qu'est-ce que l'attaque par substitution de l'algorithme en "none" ?
Si le backend fait naïvement confiance au champ alg de l'en-tête du token, un attaquant peut le remplacer par none, retirer la signature — et un token avec des données arbitraires passera la vérification. Les bibliothèques robustes exigent de préciser explicitement l'algorithme attendu lors de la vérification.
Pourquoi éviter de stocker un JWT dans localStorage pour des sessions sensibles ?
localStorage est accessible à n'importe quel code JavaScript de la page, donc vulnérable au XSS — un script malveillant peut voler le token. Pour des tokens de session, un cookie httpOnly, inaccessible au JavaScript, est plus sûr.