Décodeur et validateur de JWT
Collez un JSON Web Token pour lire son en-tête et son payload, voir quand il a été émis et quand il expire, et vérifier une signature HMAC avec votre secret partagé — sans que le jeton quitte votre machine.
- Sans inscription
- Tourne dans votre navigateur
- Fonctionne hors ligne
- Aucun envoi de fichier
- Gratuit
Un « Bearer » en tête est ignoré. Le jeton reste dans cette page.
Sert uniquement à recalculer la signature dans votre navigateur.
Un JSON Web Token, ce sont trois parties encodées en base64url et séparées par des points : un en-tête indiquant la méthode de signature, un payload de claims, et une signature portant sur les deux premières. Les deux premières parties sont seulement encodées, pas chiffrées : quiconque détient le jeton peut les lire. C'est la signature qui empêche d'en modifier le contenu.
C'est exactement pour cela que coller un jeton actif dans un site inconnu est une mauvaise habitude. Beaucoup de jetons sont des identifiants « au porteur » : celui qui en détient un peut agir au nom de l'utilisateur jusqu'à expiration. Un décodeur qui envoie votre jeton à un serveur lui remet une clé qui fonctionne. Celui-ci décode dans votre navigateur, et vérifie l'HMAC de la même façon, avec l'implémentation WebCrypto du navigateur.
Comment utiliser cet outil
- Collez le jeton. Un
Beareren tête est retiré automatiquement, vous pouvez donc coller directement depuis un en-tête Authorization. - Lisez le résumé des claims. Émetteur, sujet, audience, date d'émission et expiration sont décodés et affichés dans votre fuseau horaire, avec une durée relative en clair.
- Vérifiez la ligne d'expiration. Un jeton expiré est signalé en rouge — cela explique la plupart des réponses 401 inattendues.
- Pour un jeton HS256, HS384 ou HS512, saisissez le secret partagé et lancez la vérification. La signature est recalculée en local puis comparée.
- Copiez le payload si vous en avez besoin ailleurs.
Exemple concret
Diagnostiquer un 401
Une API refuse obstinément une requête. Vous collez le jeton et le résumé montre un exp dépassé depuis trois heures : le jeton a expiré et le client ne le renouvelle pas. Pas d'aller-retour serveur, pas de devinettes.
Confirmer un secret de signature
Un service de recette refuse les jetons émis par votre service. Vous collez un jeton, saisissez le secret de votre configuration, et la vérification échoue : les deux environnements n'utilisent pas le même secret, ce qui est tout le bug.
Cas d'usage courants
- Comprendre pourquoi une requête d'API renvoie 401 ou 403
- Vérifier quels claims votre fournisseur d'identité émet réellement
- Confirmer que deux environnements partagent le même secret de signature
- Lire l'expiration d'un jeton pendant un incident
- Expliquer le contenu d'un jeton à quelqu'un pendant une revue de code
- Vérifier un webhook signé avec une clé symétrique
Erreurs fréquentes
- Confondre décodage et vérification — N'importe qui peut décoder un JWT. Seule la vérification de la signature prouve qu'il n'a pas été modifié : vérifiez toujours côté serveur avant de faire confiance à un claim.
- Accepter alg: none — Un jeton déclarant
nonen'est pas signé. Un serveur qui respecte cet en-tête accepte n'importe quels claims. Cet outil le signale en rouge. - Mettre des secrets dans le payload — Le payload est encodé, pas chiffré. Tout ce que vous y placez est lisible par le porteur du jeton.
- Confondre secondes et millisecondes —
exp,iatetnbfsont des secondes depuis l'epoch. Passer un timestamp JavaScript en millisecondes place l'expiration environ cinquante mille ans dans le futur.
Questions fréquentes
Mon jeton est-il envoyé quelque part ?
Non. Le décodage, c'est du base64url et de l'analyse JSON, et le contrôle HMAC utilise le WebCrypto intégré à votre navigateur. Les deux se font dans la page. Rien n'est transmis — et cela compte, car un jeton actif est généralement un identifiant qui fonctionne.
Pourquoi ne puis-je pas vérifier un jeton RS256 ?
RS256 et ES256 utilisent des clés asymétriques : la vérification demande la clé publique de l'émetteur, en général récupérée sur un point d'accès JWKS. Comme cette page ne fait aucune requête réseau, elle ne peut pas aller la chercher. Les jetons HMAC symétriques sont vérifiables parce que vous fournissez vous-même le secret.
Que signifient les claims standard ?
iss est l'émetteur, sub le sujet (en général l'utilisateur), aud l'audience visée, iat la date d'émission, nbf la première date de validité, et exp l'expiration. Ces trois dates sont des secondes depuis le 1er janvier 1970 UTC.
Le jeton se décode mais la signature échoue : pourquoi ?
Le plus souvent, le secret est faux, comporte une espace en fin de chaîne, ou est encodé en base64 dans votre configuration alors qu'il est utilisé brut ici. Ce peut aussi être un algorithme différent, ou un jeton modifié en transit — ce que la signature sert précisément à détecter.
Est-il prudent de coller un jeton de production ici ?
Il ne quitte jamais votre navigateur, aucune requête ne le transporte. Cela dit, la meilleure habitude avec n'importe quel outil reste d'utiliser un jeton expiré ou de test quand c'est possible. Vous pouvez vérifier l'affirmation en coupant votre connexion internet : la page continue de fonctionner.
Puis-je décoder un jeton chiffré (JWE) ?
Non. Cet outil traite les jetons signés (JWS), ce qu'utilisent presque toutes les API. Un jeton JWE chiffré comporte cinq parties au lieu de trois et nécessite la clé de déchiffrement.
Dernière mise à jour 2026-09-15