🔑 Décodeur JWT ☆

Aperçu

Décodeur JWT décode tout JSON Web Token directement dans votre navigateur. Collez un token et voyez instantanément ses trois parties : l en-tête (algorithme, type, key ID), le payload (tous les claims en JSON formaté) et la signature brute. Les claims de temps sont traduits en dates lisibles et l outil indique si le token est valide, expiré, pas encore valide ou sans expiration. Tout s exécute côté client, votre token n est jamais envoyé, ce qui compte car les JWT contiennent souvent des identifiants de session. Décoder ne vérifie pas la signature.

Ce que contient un JWT

Un JWT est composé de trois segments base64url séparés par des points. L'en-tête indique l'algorithme de signature et le key id ; le payload porte des claims comme iss (émetteur), sub (sujet), aud (audience), exp (expiration), iat (émis à) et nbf (pas avant) ; la signature permet à un serveur de vérifier l'émetteur et l'intégrité. Le décodeur affiche les trois, formate le JSON, humanise les dates et indique si le token est valide, expiré ou pas encore actif.

Spécifications et compatibilité

Propriété	Comportement
Entrée	Tout token JWS (header.payload.signature)
Parties décodées	En-tête, claims du payload et signature brute
Claims de temps	exp, iat, nbf en dates lisibles avec statut
Statut	Valide, expiré, pas encore valide ou sans expiration
Signature	Non vérifiée: décodage uniquement
Traitement	100 % côté client ; tokens jamais envoyés
Coût	Gratuit, sans compte, tokens illimités

Confidentialité : les tokens de session restent dans le navigateur

Un JWT est souvent une vraie credential, le coller dans un décodeur en ligne livrerait une session active. Tout est décodé localement : rien n'est transmis ni stocké. Traitez aussi la sortie comme sensible.

Déboguer des JWT sans risque

• Vérifiez exp d'abord : la plupart des « token invalide » sont expirés.
• Comparez iat et nbf quand les horloges dérivent.
• Contrôlez que aud et iss correspondent à l'API.
• alg: none et les algorithmes symétriques exigent une validation serveur rigoureuse.
• Ne collez jamais de tokens de production dans un outil non maîtrisé.

Voir aussi les outils de développement pour Base64, hachage et regex.

Structure JWT, signatures et erreurs courantes

Un JSON Web Token comporte trois parties séparées par des points : un en-tête décrivant l'algorithme, une charge utile portant les claims et une signature permettant au récepteur de vérifier que les deux premières n'ont pas été modifiées. Les trois sont encodées en Base64URL, c'est-à-dire un encodage et non un chiffrement : quiconque détient le token peut lire les claims, donc rien de sensible ne doit figurer dans la charge. Le décodage est donc toujours sûr en local, tandis que la vérification exige le secret ou la clé publique et doit se faire côté serveur. Plusieurs erreurs reviennent dans les vrais systèmes. L'attaque alg:none exploite les bibliothèques qui faisaient confiance à l'en-tête et acceptaient un token non signé ; une implémentation correcte fixe l'algorithme attendu et rejette le reste. Utiliser HS256, algorithme symétrique, avec un secret faible ou divulgué en est une autre : le secret doit être long et aléatoire, et les algorithmes asymétriques comme RS256 sont préférables quand beaucoup doivent vérifier mais qu'un seul peut signer. La validation des claims s'oublie facilement : exp et nbf doivent être comparés à l'heure courante, iss et aud doivent correspondre aux valeurs attendues, et jti permet la révocation en cas de vol. Les tokens sont des identifiants porteurs : ils ne doivent circuler qu'en HTTPS et être stockés là où les scripts ne peuvent pas les lire si le XSS est une préoccupation. Rappelez-vous qu'un token décodé ne prouve rien tant que la signature n'est pas vérifiée. Cet outil décode en local et ne stocke rien.