Outils Nettoyage
Blog Home

Décodeur JWT en ligne gratuit

Décodez et inspectez les JSON Web Tokens directement dans votre navigateur. Affichez l'en-tête, le payload et les claims avec des dates d'expiration lisibles. Rien n'est jamais envoyé à un serveur.

Inspecteur de token

Algorithme
—
Type
—
Expiration
—

En-tête (Header)

Payload

Signature

La vérification de la signature nécessite la clé secrète et n'est pas prise en charge par cet outil.
Tout le décodage se fait localement dans votre navigateur. Votre token n'est jamais téléversé, stocké ni journalisé.

Qu'est-ce qu'un JWT ?

Un JSON Web Token (JWT, RFC 7519) est un moyen compact et sûr pour les URL de représenter des claims entre deux parties. Il se compose de trois parties encodées en Base64URL reliées par des points — header.payload.signature. Son usage le plus courant est l'authentification sans état des API REST : après connexion, le serveur émet un token signé que le client envoie à chaque requête, ce qui permet au serveur de vérifier l'identité sans conserver d'état de session.

Structure d'un JWT : Header, Payload, Signature

En-tête (Header)

Déclare l'algorithme de signature (alg, ex. HS256, RS256, ES256) et le type de token (typ), presque toujours JWT.

Payload

Contient les claims standard et personnalisés. Il est seulement encodé en Base64URL, pas chiffré — n'importe qui peut le lire, n'y stockez donc jamais de secrets.

Signature

Calculée en signant l'en-tête et le payload encodés avec une clé secrète ou privée. Elle prouve l'intégrité mais ne peut pas être vérifiée sans cette clé.

Les claims JWT courants expliqués

Le payload contient des claims — des affirmations sur le token. Ces claims enregistrés sont définis par la norme JWT :

sub Subject — le sujet concerné par le token, généralement l'ID utilisateur.
iss Issuer — identifie l'émetteur du token.
aud Audience — les destinataires auxquels le token est destiné.
exp Expiration Time — horodatage Unix après lequel le token doit être rejeté.
iat Issued At — horodatage Unix de la création du token.
nbf Not Before — horodatage Unix avant lequel le token ne doit pas être accepté.
jti JWT ID — un identifiant unique, utile pour empêcher la réutilisation du token.

Bonnes pratiques de sécurité JWT

Ne placez jamais de données sensibles dans le payload — il est seulement encodé, pas chiffré, et lisible par tous.
Définissez toujours un claim exp et gardez des durées de vie courtes pour limiter l'impact d'un token divulgué.
Préférez les algorithmes asymétriques (RS256 ou ES256) pour les microservices afin que les services puissent vérifier sans partager de secret.
Validez toujours les claims iss et aud côté serveur et rejetez les tokens dont l'alg est défini sur none.
N'exposez jamais les tokens dans les URL ou les fichiers de log ; envoyez-les dans l'en-tête Authorization et stockez-les en sécurité.

Foire aux questions

Non. Un JWT standard est signé, pas chiffré. L'en-tête et le payload sont seulement encodés en Base64URL, ce qui signifie que toute personne disposant du token peut en décoder et lire le contenu. La signature garantit seulement que le token n'a pas été altéré — elle ne masque pas les données. Si vous avez besoin de confidentialité, utilisez JWE (JSON Web Encryption) ou ne placez jamais de données sensibles dans le payload.

Non. Vérifier la signature d'un JWT nécessite la clé secrète (pour HS256) ou la clé publique (pour RS256/ES256), que seul le serveur émetteur devrait détenir. Cet outil décode volontairement le token côté client sans vérification, afin qu'aucune clé ne quitte jamais votre appareil. Vérifiez toujours les signatures sur votre serveur, jamais dans le navigateur.

HS256 est symétrique : la même clé secrète signe et vérifie le token, donc toute partie capable de vérifier peut aussi forger des tokens. RS256 est asymétrique : une clé privée signe et une clé publique distincte vérifie. RS256 est préféré pour les systèmes distribués et les microservices car vous pouvez partager librement la clé publique tout en gardant secrète la clé privée de signature.

Le claim exp est un horodatage Unix en secondes. Une erreur fréquente est de le fournir en millisecondes (13 chiffres) au lieu de secondes (10 chiffres), ce qui place l'expiration loin dans le passé ou le futur. Le décalage d'horloge entre serveurs peut aussi provoquer une expiration prématurée — prévoyez une petite marge lors de la validation. Utilisez l'Inspecteur de token ci-dessus pour voir la date d'expiration lisible à côté de la valeur brute.