Décodeur de JWT gratuit

Décodez l'en-tête, le payload et les claims d'un JWT localement — avec vérification facultative de signature HMAC. Rien ne quitte votre navigateur.

Le décodeur de JWT lit les JSON Web Tokens que vos API émettent et consomment — la forme compacte header.payload.signature utilisée par OAuth 2.0, OpenID Connect et d'innombrables bibliothèques d'authentification — et les rend en JSON lisible et mis en forme : l'en-tête avec son algorithme et son identifiant de clé, le payload avec ses claims, et le segment de signature brut. Le décodage se déroule entièrement dans votre navigateur : le décodage base64url et l'analyse JSON sont locaux, si bien que l'outil est sûr même avec des jetons de production portant de vrais identifiants d'utilisateur, des e-mails et des détails de session — rien n'est envoyé, journalisé ou stocké. Ce que ce décodeur ne fera pas, c'est en faire trop. Il peut vérifier une signature HMAC lorsque vous collez le secret : l'outil calcule le HMAC avec WebCrypto et rapporte Signature valide ou Signature invalide, pour que vous confirmiez qu'un jeton a réellement été signé avec le secret que vous détenez et n'a pas été altéré en transit. Cette vérification est honnête sur sa portée : seuls HS256, HS384 et HS512 peuvent être vérifiés avec un secret partagé dans le navigateur. Les jetons asymétriques — RS256, ES256, PS256 et leurs semblables — sont la norme en production, et les vérifier exige la clé publique du signataire, qu'un outil côté client ne peut pas obtenir pour vous ; le décodeur le dit exactement au lieu de deviner. Les jetons avec alg=none, la configuration tristement célèbre et dangereuse, sont signalés comme non protégés, sans signature. Les claims d'expiration et d'émission (exp, iat, nbf) apparaissent sous leur forme epoch brute dans le JSON du payload, exactement comme le jeton les porte — l'outil ne convertit ni n'interprète, car la conversion silencieuse est là où les décodeurs mentent. Collez un jeton de vos journaux, de votre inspecteur réseau ou de vos tests et lisez-le comme le serveur le lirait.

Traité localement dans votre navigateur

Comment le résultat est-il calculé ?

Lire un jeton d'identité depuis vos journaux

Les journaux d'accès de votre service contiennent un jeton comme l'exemple de la RFC 7515 — un en-tête déclarant HS256, un payload avec un subject, un nom et une heure d'émission, et un segment de signature. Décodez-le pour lire les claims comme le serveur le ferait, puis collez le secret partagé pour confirmer que la signature correspond réellement — un sub altéré ou un iat expiré apparaît comme Signature invalide.

Exemple d'entrée et de sortie
Entrée	Valeur
Jeton	`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`
Secret HMAC (facultatif)	`your-256-bit-secret`
Résultat	{"sub":"1234567890","name":"John Doe","iat":1516239022} — Signature valide

Quelle est la formule et ses hypothèses ?

Sérialisation compacte JWT

JWT = base64url(header) + "." + base64url(payload) + "." + base64url(signature)

Termes de la formule
Symbole	Signification
`header`	l'en-tête JSON : alg, typ et souvent kid — l'algorithme de signature et l'identifiant de clé
`payload`	les claims JSON : enregistrés (sub, iat, exp, nbf, iss, aud) plus les claims personnalisés
`base64url`	base64 avec des caractères sûrs pour les URL (- et _) et sans remplissage

RFC 7519 §3.1. L'outil décode les segments en base64url et met le JSON en forme ; il ne réordonne ni n'interprète jamais les claims.

Vérification de signature HMAC

valide = verify(HMAC-{SHA-256|384|512}(secret), base64url(header.payload), signature)

Termes de la formule
Symbole	Signification
`secret`	le secret HMAC partagé que vous collez — utilisé uniquement dans le navigateur, jamais envoyé
`base64url(header.payload)`	l'entrée de signature : les deux premiers segments exactement comme le jeton les porte
`signature`	le troisième segment, décodé vers les octets MAC bruts

crypto.subtle.verify effectue une comparaison en temps constant, donc une divergence ne fuit jamais de timing. Les algorithmes asymétriques exigent la clé publique du signataire et sont signalés comme non vérifiables localement.

Quelles sont les erreurs les plus courantes ?

Faire confiance à un jeton parce qu'il se décode — décoder montre les claims, pas qui les a signés ; seule une vérification de signature valide prouve l'origine, et uniquement pour les jetons HMAC avec le bon secret.
Supposer que les jetons alg=none étaient « inoffensifs à décoder » — ils ne sont pas signés et doivent être rejetés par toute bibliothèque qui les accepte.
Coller des jetons de production dans des décodeurs en ligne qui les envoient — cet outil est entièrement local ; de nombreux services web conservent votre jeton et vos claims.

Quelles sont les hypothèses et les limites ?

La vérification de signature couvre uniquement HMAC (HS256/384/512) — les jetons asymétriques sont signalés comme non vérifiables localement.
Les claims sont affichés bruts (secondes epoch pour exp/iat/nbf) ; l'outil ne les convertit pas.
Les jetons d'accès opaques ne sont pas des JWT et ne peuvent pas être décodés.

D'où viennent les chiffres ?

Dernière révision 12 août 2026 · Version 1.0.0 · Toolivaro ne garantit pas les contenus externes.

Questions fréquentes

Mon jeton est-il envoyé quelque part ?

Non. Le décodage et la vérification de signature s'exécutent entièrement dans votre navigateur avec WebCrypto — aucune requête réseau n'est émise avec votre jeton ni votre secret. Cela rend l'outil sûr même pour des jetons de production portant de vrais claims d'utilisateurs.

Pourquoi ne pouvez-vous pas vérifier les jetons RS256 ?

RS256 et les autres familles asymétriques sont vérifiées avec la clé publique du signataire, qui vit sur l'endpoint JWKS de l'émetteur — un outil côté client n'a aucun moyen fiable d'obtenir et de faire confiance à cette clé pour vous. Le décodeur signale ces jetons comme non vérifiables localement au lieu de simuler un résultat. Les jetons HMAC (HS256/384/512) n'exigent que le secret partagé, donc ceux-là sont vérifiés lorsque vous le fournissez.

Que signifie alg=none sur un jeton ?

alg=none déclare que le jeton n'a pas été signé du tout. Les bibliothèques qui acceptent none sont à l'origine de célèbres contournements d'authentification. Le décodeur signale ces jetons comme non protégés, sans segment de signature à vérifier.

Pourquoi exp et iat sont-ils affichés en nombres bruts ?

Parce que c'est ainsi que le jeton les porte — des secondes epoch NumericDate conformément à la RFC 7519. L'outil ne convertit ni n'interprète les claims en silence : la conversion silencieuse est là où les décodeurs mentent, et la valeur brute est la vérité que voit le serveur.

Cet outil peut-il décoder les jetons d'accès OAuth 2.0 ?

Seulement s'ils sont des JWT. De nombreux fournisseurs (Okta, Auth0, Azure AD) émettent des jetons d'accès JWT, et ceux-là se décodent ici. Les jetons opaques — des chaînes aléatoires qui ne sont que des identifiants — n'ont pas de JSON à l'intérieur et ne sont pas des JWT ; aucun décodeur ne peut les transformer en claims.

Fait partie de Outils de mots de passe, hachage et sécurité

Vous avez repéré une erreur ou souhaitez une correction ? Signalez-la — chaque correction est examinée.

Ce calculateur vous a été utile ?

Relu par l'équipe éditoriale de Toolivaro selon notre méthodologie Méthodologie · Politique éditoriale