Dev Tools

Décodeur JWT

Décodez et analysez vos tokens JWT en ligne. En-tête, payload, signature : tout est visible en un clic.

Besoin d'encoder des données en Base64 ?

Encodez et décodez du texte en Base64 avec support UTF-8.

Encoder en Base64

Estimation indicative. Ne constitue pas un conseil fiscal ou financier. Consultez un professionnel pour votre situation personnelle.

Questions fréquentes

Quelle est la structure d'un token JWT ?

Un JWT (JSON Web Token) est composé de trois parties séparées par des points : l'en-tête (header), la charge utile (payload) et la signature.

Chaque partie est encodée en Base64URL. L'header indique le type de token et l'algorithme de signature. Le payload contient les claims (données). La signature garantit l'intégrité du token.

Quelle est la différence entre RS256 et HS256 ?

HS256 (HMAC-SHA256) utilise une clé secrète symétrique partagée entre l'émetteur et le vérificateur : simple mais moins flexible. RS256 (RSA-SHA256) utilise une paire de clés asymétriques : la clé privée signe le token, la clé publique le vérifie.

RS256 est recommandé pour les architectures distribuées car la clé publique peut être partagée librement sans compromettre la sécurité.

À quoi sert le claim exp dans un JWT ?

Le claim exp (expiration time) est un timestamp Unix indiquant la date et l'heure au-delà desquelles le token ne doit plus être accepté. Il est exprimé en secondes depuis le 1er janvier 1970 (epoch).

Par exemple, exp: 1700000000 correspond à novembre 2023. Un serveur doit toujours vérifier que la date courante est inférieure à exp avant d'accepter un token.

Est-il sécurisé de décoder un JWT côté client ?

Décoder un JWT (lire son contenu) est toujours possible sans clé, car l'encodage Base64URL n'est pas un chiffrement. Cet outil décode uniquement : il ne valide pas la signature cryptographique.

Pour une utilisation en production, la vérification de la signature doit impérativement être effectuée côté serveur avec la clé appropriée. Ne jamais faire confiance à un JWT sans vérifier sa signature côté serveur.

Où utilise-t-on les JWT en pratique ?

Les JWT sont utilisés pour l'authentification (Bearer token dans les headers HTTP Authorization), les sessions stateless, l'échange d'informations entre services (microservices, API REST), le SSO (Single Sign-On) et les webhooks signés.

Ils sont particulièrement adaptés aux architectures distribuées où plusieurs services doivent vérifier l'identité d'un utilisateur sans interroger une base de données centrale.

JWT decoder online : tout savoir sur les JSON Web Tokens

Qu'est-ce qu'un JWT ?

Un JWT (JSON Web Token) est un standard ouvert défini par la RFC 7519 (IETF, 2015) qui permet de transmettre des informations de manière compacte et sécurisée entre deux parties sous la forme d'un objet JSON signé. Le token est composé de trois parties séparées par des points : le header (en-tête), le payload (charge utile) et la signature.

Chaque partie est encodée en Base64URL (une variante du Base64 adaptée aux URLs). Le header indique l'algorithme de signature utilisé (HS256, RS256, etc.) et le type de token. Le payload contient les claims (revendications), c'est-à-dire les données transportées par le token. La signature garantit l'intégrité du token et permet de vérifier qu'il n'a pas été modifié.

header.payload.signature → eyJhbGci...eyJzdWIi...SflKxwRJ...

Structure détaillée d'un JWT

Les trois parties d'un JWT

Header
Algorithme (alg) et type (typ)
Payload
Claims : sub, iss, exp, iat, données custom
Signature
HMAC ou RSA du header + payload

Chaque partie est encodée en Base64URL et séparée par un point

Les claims du payload se divisent en trois catégories : les claims enregistrés (définis par la RFC : sub, iss, exp, iat, aud, nbf, jti), les claims publics (enregistrés dans le registre IANA) et les claims privés (définis par les parties utilisant le token).

8 Ko

taille maximale recommandée d'un JWT pour rester compatible avec les headers HTTP courants

HS256 vs RS256 : quel algorithme choisir ?

HS256 (symétrique)

1 clé

Même secret pour signer et vérifier

RS256 (asymétrique)

2 clés

Clé privée pour signer, publique pour vérifier

L'algorithme HS256 (HMAC-SHA256) utilise une clé secrète symétrique partagée entre l'émetteur et le vérificateur. Il est simple à mettre en place mais impose que toutes les parties connaissent le secret. L'algorithme RS256 (RSA-SHA256) utilise une paire de clés asymétriques : la clé privée signe le token et la clé publique le vérifie.

RS256 est recommandé pour les architectures distribuées et les systèmes de SSO (Single Sign-On) car la clé publique peut être distribuée librement via un endpoint JWKS (JSON Web Key Set) sans compromettre la sécurité. HS256 convient aux architectures simples où un seul service émet et vérifie les tokens.

Ne jamais faire confiance à un JWT non vérifié

Le décodage d'un JWT (lecture du header et du payload) est toujours possible sans clé, car le Base64URL n'est pas du chiffrement. En production, vous devez impérativement vérifier la signature côté serveur avant d'accorder une quelconque confiance aux données du payload.

Cas d'utilisation des JWT

  • Authentification API : le token est transmis dans le header Authorization: Bearer <token> à chaque requête.
  • Sessions stateless : le serveur n'a pas besoin de stocker l'état de la session, toutes les informations sont dans le token.
  • SSO (Single Sign-On) : un serveur d'identité émet un JWT que plusieurs services peuvent vérifier indépendamment.
  • Échange inter-services : dans les architectures microservices, les JWT permettent de propager l'identité entre services.

Erreurs fréquentes à éviter

  • Stocker des données sensibles dans le payload. Le payload est lisible par quiconque possède le token. N'y mettez jamais de mots de passe, de numéros de carte bancaire ou de données médicales.
  • Ne pas vérifier la signature. Accepter un JWT sans vérifier sa signature permet à un attaquant de forger un token avec les claims de son choix.
  • Utiliser alg: "none". Certaines bibliothèques acceptent l'algorithme none, qui désactive la signature. Configurez toujours une liste blanche d'algorithmes autorisés.
  • Définir une durée de vie trop longue. Un token avec un exp de plusieurs jours reste valide même si l'utilisateur a été désactivé. Préférez des durées courtes (15 min) avec un mécanisme de refresh token.
  • Confondre JWS et JWE. Un JWT signé (JWS) garantit l'intégrité mais pas la confidentialité. Pour chiffrer le contenu, utilisez JWE (JSON Web Encryption, RFC 7516).

Sources et références

Dev & Tech

Convertisseur CSV vers JSON
Encodeur/Décodeur Base64
Calculateur Chmod
Générateur UUID
Générateur Meta Tags
Générateur Dégradé CSS

Sources : RFC 7519 (JWT, IETF, 2015) · RFC 7515 (JWS) · RFC 7518 (JWA) · MDN Web Docs. Traitement 100 % côté client, aucun token n'est transmis à un serveur. Dernière mise à jour : avril 2026.