Encodeur / décodeur JWT

Que signifie « decoder un JWT » ?

Decoder un JWT (« jwt decode », « decode jwt online ») revient à couper la chaîne aux deux points, puis à décoder chaque segment en Base64URL pour retrouver le JSON d'origine. Aucune clé n'est nécessaire : l'en-tête et le payload sont simplement encodés, pas chiffrés. C'est exactement l'intention derrière « jwt payload decoder » ou « decode jwt without verify » — voir ce que contient le jeton, sans prétendre qu'il est authentique.

Attention à bien distinguer les deux gestes. Lire un JWT ne prouve rien : n'importe qui peut fabriquer un jeton au payload séduisant et le signer avec son propre secret. Vérifier la signature prouve que le contenu n'a pas été modifié par un tiers. Un décodeur qui affiche « admin: true » sans contrôle de signature vous raconte une histoire, pas un fait.

Les trois segments d'un JWT

La chaîne se découpe exactement en trois parties séparées par des points : header.payload.signature. L'en-tête contient au minimum alg et typ, parfois kid pour indiquer quelle clé a servi. Le payload contient les claims, ces paires clé-valeur dont le registre est tenu par l'IANA. La signature couvre les deux premiers segments concaténés exactement comme ils sont écrits — la moindre modification d'un espace ou d'un caractère casse la comparaison.

Toute la difficulté vient du fait que ces segments sont en Base64URL et non en Base64 : le signe plus devient un tiret, la barre oblique devient un souligné, et le remplissage = disparaît. Un décodeur Base64 classique échouera donc sur un JWT valide. Le tableau « Base64URL contre Base64 classique » de l'onglet référence montre précisément ces substitutions.

Comment vérifier une signature : HS256, RS256, ES256

Pour un algorithme HMAC — HS256, HS384, HS512 — le même secret sert à signer et à vérifier : l'outil recalcule HMAC(secret, base64url(header) + "." + base64url(payload)) et compare le résultat à la signature transportée. C'est le cas le plus courant, et aussi le plus dangereux : tout service qui détient le secret peut émettre un jeton. Un secret de moins de 32 octets, réutilisé entre environnements, suffit à compromettre toute la chaîne.

Pour les algorithmes asymétriques — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — vous n'avez besoin que de la clé publique pour vérifier, ce qui permet de contrôler un jeton émis par un tiers sans jamais partager son secret de signature. Collez la clé au format PEM -----BEGIN PUBLIC KEY----- (SPKI) ; le résultat brut d'un export OpenSSL est directement utilisable. Pour ES256, la signature est en format r||s brut, celui que WebCrypto attend.

Il faut enfin se méfier de l'alg confusion : si votre service attend RS256 mais accepte un jeton dont l'en-tête déclare HS256, un attaquant signera avec la clé publique — devenue clé HMAC — et passera la vérification. Figez l'algorithme attendu côté serveur, ne le lisez jamais du jeton lui-même.

exp, iat, nbf : les horodatages qui piègent

Ces trois claims sont des secondes Unix, sans milliseconde et sans fuseau : iat à 1516239022 signifie 2018-01-17T21:30:22Z. Deux erreurs reviennent sans cesse : comparer à une date en millisecondes (valeur dix mille fois trop grande) et interpréter un timestamp comme local plutôt qu'en UTC. L'onglet « Expiration » convertit dans les deux sens, affiche l'ISO 8601, la date locale et le temps restant ou écoulé — de quoi repérer immédiatement un jeton « déjà expiré » à la seconde d'horloge près.

Prolonger la durée de vie n'élève pas le niveau de sécurité : un exp repoussé change la valeur affichée, pas la signature. Si vous devez réémettre, re-signez le jeton avec le secret ou la clé privée — c'est exactement le rôle de l'onglet « Encoder ».

Base64URL : pourquoi les décodeurs classiques échouent

Base64URL (RFC 4648 §5) utilise l'alphabet A-Z a-z 0-9 - _ et n'admet pas de remplissage. Un payload de 20 caractères produit souvent une longueur non multiple de quatre après suppression du = : c'est normal, pas une corruption. Les caractères - et _ sont ambigus pour un œil humain, ce qui explique la moitié des « jetons cassés » rapportés. Notre décodeur accepte les deux alphabets, la casse mixte, le remplissage optionnel et un préfixe Bearer.

Sécurité : ce qu'un JWT ne fait pas

Un JWT n'offre ni confidentialité ni révocation. Le payload est lisible par tous : jamais d'e-mail, de rôle interne ou de donnée personnelle que vous n'accepteriez d'envoyer en clair. Et un jeton signé reste valide jusqu'à exp même après déconnexion — il faut une liste de révocation, un jti suivi côté serveur, ou des durées de vie courtes avec refresh token. Un bon réflexe : exp court (10 à 15 minutes), iat contrôlé, nbf aligné sur iat, aud et iss vérifiés à réception.

Recommandé pour

Développeurs back-end et front-end (OAuth 2.0, OpenID Connect, API REST), intégrateurs et DevOps (infrastructure d'identité, JWKS, rotation de clés), test·euses et pentesteurs (réécriture de claims, alg confusion, expiration), administrateur·es de systèmes (débogage d'un 401 inexplicable), étudiants (comprendre Base64URL et WebCrypto), et toute personne qui a besoin d'un décodeur JWT en ligne rapide, complet et confidentiel — avec pour compléments l'encodeur décodeur Base64, l'encodeur décodeur URL et le formateur JSON.

Décodeur JWT 100 % local : votre jeton ne quitte jamais votre ordinateur

Contrairement aux décodeurs JWT en ligne classiques, aucune chaîne n'est transmise : le décodage, la vérification de signature et l'encodage s'exécutent entièrement dans votre navigateur via WebCrypto, sans bibliothèque tierce ni requête réseau. C'est ce qui permet d'inspecter un jeton de session réel, une clé de staging ou un token de service interne sans risque, même hors connexion ou sur un réseau public. L'historique et la dernière saisie sont conservés localement (localStorage) et restent sur votre appareil.

La licence Premium Volade ajoute une synchronisation cloud facultative, chiffrée, indépendante de l'outil — le reste demeure gratuit et illimité, sans inscription.