Ce que fait ce décodeur JWT
Un JSON Web Token se compose de trois parties encodées en Base64URL séparées par des points : l'en-tête (algorithme et type), le payload (claims) et la signature. Ce décodeur JWT en ligne sépare ces trois segments et affiche leur contenu JSON formaté en un clic — sans jamais transmettre votre token à un serveur. Cette version française est conçue pour les développeurs francophones qui déboguent des flux OAuth 2.0, OpenID Connect ou des API REST sécurisées. Toute l'opération de décodage se déroule 100 % dans le navigateur — vos données ne quittent jamais votre machine. Pas d'upload, pas de tracking, pas de logs serveur. Notez que décoder un token n'équivaut pas à le vérifier : les claims lus ne doivent jamais être utilisés pour des décisions d'autorisation sans que la signature ait été validée côté serveur avec la clé appropriée.
Fonctionnalités
- Décodage instantané header / payload. Collez un token JWT ou un bearer token : l'en-tête et le payload sont affichés en JSON indenté en moins d'une milliseconde, sans rechargement de page.
- Mise en évidence des claims standards. Les claims RFC 7519 — iss, sub, aud, exp, iat, nbf, jti — sont identifiés et libellés explicitement pour faciliter la lecture, notamment lors du débogage de tokens d'accès expirés.
- Statut d'expiration en temps réel. Le champ exp est comparé à l'heure locale : le décodeur indique immédiatement si le token est expiré ou encore valide, avec la date et l'heure exactes formatées selon le fuseau Europe/Paris.
- Détection de l'algorithme. L'algorithme déclaré dans l'en-tête (HS256, RS256, ES256…) est affiché en évidence. Cela aide à repérer une configuration inattendue, y compris le cas dangereux alg=none.
- Copie en un clic. Chaque section — en-tête, payload, signature brute — dispose d'un bouton Copier pour coller rapidement dans votre terminal ou votre suite de tests.
- Confidentialité totale. Aucune requête réseau n'est émise. Le décodage s'effectue via
JSON.parse(atob(token.split('.')[1]))directement dans votre navigateur, ce qui le rend sûr même pour les tokens contenant des données personnelles.
Comment utiliser le décodeur JWT
Collez votre token dans le champ, appuyez sur Entrée ou cliquez sur Décoder — le résultat s'affiche immédiatement en trois panneaux.
- Copiez votre token. Récupérez le JWT depuis votre application, les DevTools du navigateur ou votre client REST. Le préfixe « Bearer » est accepté et ignoré automatiquement.
- Collez dans le champ. Déposez le token dans la zone de saisie. Le décodage est lancé à la volée ; aucune validation de formulaire n'est requise.
- Lisez header et payload. L'en-tête révèle l'algorithme (
alg) et le type (typ). Le payload liste tous vos claims : en Python, vous obtiendriez le même résultat avecimport jwt; jwt.decode(token, options={'verify_signature': False}). - Vérifiez le statut d'expiration. Le panneau de statut indique si le claim exp est dépassé. Utile pour diagnostiquer une erreur 401 avant même d'interroger votre serveur d'autorisation.
- Copiez la section utile. Cliquez sur Copier sous le panneau souhaité pour exporter le JSON formaté vers votre éditeur ou votre outil de débogage.
Cas d'usage courants
- Débogage de tokens OAuth 2.0 expirés. Lorsqu'une API renvoie une erreur 401 à Bruxelles ou Strasbourg, vérifiez instantanément si le claim exp est dépassé sans avoir à décoder manuellement la chaîne Base64URL.
- Inspection des claims aud et iss. Les erreurs d'audience ou d'émetteur sont courantes lors de l'intégration d'un provider OIDC. Ce JWT parser affiche ces valeurs clairement pour comparer avec la configuration attendue.
- Lecture de claims personnalisés. Les fournisseurs d'identité (Keycloak, Auth0, Azure AD) injectent des rôles ou des métadonnées dans le payload. Parsez le token pour inspecter ces claims sans écrire de code.
- Validation du format avant les tests d'intégration. Avant de lancer votre suite de tests, décodez un access token de staging pour vous assurer que les claims attendus sont présents et correctement formés.
- Vérification rapide en environnement de développement. En phase de développement local, décoder un bearer token permet de valider la chaîne de signature et la structure du header sans dépendre d'un outil externe ou d'une bibliothèque.
Questions fréquentes
Ce décodeur envoie-t-il mon token à un serveur ?
Non. L'intégralité du traitement s'effectue dans votre navigateur via JavaScript. Aucune donnée — y compris les tokens contenant des informations personnelles — ne quitte votre machine. Il n'existe ni log serveur, ni analytics collectant le contenu de la zone de saisie.
Quelle est la différence entre décoder et vérifier un JWT ?
Décoder consiste à lire le contenu Base64URL du token, ce qui ne nécessite aucune clé. Vérifier consiste à valider la signature cryptographique (HMAC, RSA ou ECDSA) à l'aide du secret partagé ou de la clé publique. Comme recommandé par le NIST SP 800-63B, les décisions d'autorisation doivent toujours reposer sur une signature vérifiée côté serveur, jamais sur un simple décodage.
Pourquoi voit-on parfois « alg: none » dans le header ?
La valeur alg=none signifie qu'aucune signature n'est appliquée. Certaines bibliothèques l'acceptaient par défaut, ouvrant une faille critique : un attaquant pouvait forger un token valide sans connaître le secret. Aujourd'hui, toute implémentation sérieuse doit rejeter explicitement alg=none en production.
Puis-je décoder un token contenant des caractères accentués ?
Oui. Les caractères accentués (é, è, ç) occupent deux octets en UTF-8, mais l'encodage Base64URL les gère correctement. L'IETF, qui maintient plus de 9 500 RFC dont la spécification JWT (RFC 7519), définit précisément ce comportement. Le décodeur affiche ces caractères tels quels dans le payload JSON.
JWT et JWE sont-ils la même chose ?
Non. Un JWT signé (JWS) a un payload lisible encodé en Base64URL. Un JWE (JSON Web Encryption) chiffre le payload : sans la clé privée, le contenu est illisible. Cet outil ne prend en charge que les JWS — si votre token contient cinq segments séparés par des points, il s'agit probablement d'un JWE.
Comment gérer les problèmes de décalage horaire avec exp et nbf ?
Les claims exp (expiration) et nbf (not before) sont des timestamps Unix en secondes. Un décalage d'horloge entre le serveur émetteur et le serveur de validation peut invalider un token pourtant récent. La plupart des bibliothèques JWT autorisent une tolérance de quelques secondes (leeway). Ce décodeur affiche les valeurs brutes et les dates lisibles pour vous aider à diagnostiquer ces écarts.