Skip to content

Décodeur JWT

Collez un jeton, voyez chaque claim. Décodé dans votre navigateur — sans serveur, sans fuite.

Avertissement de sécurité — Ne collez jamais de JWT de production avec des secrets actifs dans un outil en ligne, y compris celui-ci. Utilisez uniquement des jetons de développement. Le décodage se fait dans votre navigateur — aucun réseau n'est utilisé.

Comment fonctionne le décodeur

Un JWT se compose de trois segments encodés en Base64URL séparés par des points : en-tête, contenu et signature. Cet outil divise le jeton sur les points, décode chaque segment en Base64URL via TextDecoder pour une correcte gestion UTF-8, puis affiche le JSON parsé. L'algorithme (alg) et le type (typ) de l'en-tête sont affichés sous forme de badges. Les claims standards (iss, sub, aud, exp, iat, nbf) sont décodés avec des horodatages lisibles.

La vérification optionnelle de la signature HS256 utilise l'API Web Crypto (HMAC-SHA256) entièrement dans le navigateur. Activez-la, entrez votre secret HMAC, et l'outil vérifie si la signature correspond. Aucune donnée ne quitte jamais votre navigateur.

Sources

La structure JWT est définie dans la RFC 7519 — JSON Web Token (JWT) (rfc-editor.org/rfc/rfc7519). Cette RFC spécifie la structure en trois parties, les noms de claims enregistrés et l'encodage Base64URL.

Les algorithmes de signature (HS256, RS256, ES256, etc.) sont définis dans la RFC 7518 — JSON Web Algorithms (JWA) (rfc-editor.org/rfc/rfc7518). Cet outil ne vérifie que HS256 (HMAC-SHA256) en v1.

Ce qui est là — et ce qui ne l'est pas

Décodage complet du JWT : en-tête (alg, typ), contenu avec tous les claims personnalisés, affichage de la signature. Claims standards (exp, iat, nbf) affichés en horodatages ISO lisibles avec temps relatif (ex. 'expiré il y a 3 jours'). Vérification optionnelle de la signature HS256 via Web Crypto. Avertissement de sécurité rappelant de ne pas coller de tokens de production.

Ce qui n'est pas là : le déchiffrement JWE (JSON Web Encryption) — les tokens chiffrés nécessitent une clé privée et sont fondamentalement différents des JWT signés. La vérification de signature RS256, ES256, PS256 — les algorithmes asymétriques nécessitent la clé publique en format PEM ou JWK (v2). La génération ou la signature de tokens n'est pas non plus supportée, c'est un décodeur et inspecteur, pas un outil d'authentification.

Structure JWT : trois parties expliquées

Un JWT se compose de trois parties encodées en Base64URL séparées par des points : en-tête.contenu.signature. Chaque partie est encodée indépendamment et peut être décodée sans clé.

En-tête : spécifie l'algorithme ("alg") et le type de jeton. Exemple : {"alg": "HS256", "typ": "JWT"}. Algorithmes courants : HS256 (HMAC-SHA256, symétrique), RS256 (RSA-SHA256, asymétrique), ES256 (ECDSA-SHA256).

Contenu (claims) : les données transportées dans le jeton. Claims standards : sub (sujet/ID utilisateur), iss (émetteur), exp (horodatage d'expiration), iat (émis à), nbf (pas avant). Des claims personnalisés peuvent être ajoutés librement.

Signature : créée en signant base64(en-tête) + "." + base64(contenu) avec la clé secrète du serveur. La vérification de la signature garantit que le jeton n'a pas été modifié.

L'en-tête et le contenu ne sont PAS chiffrés — ils sont seulement encodés en Base64URL. Quiconque possède le jeton peut les lire. Les signatures garantissent l'intégrité, pas la confidentialité.

Outils connexes : Encodeur / décodeur Base64, Formateur JSON, Générateur de hachage, et Encodeur URL.

Sécurité JWT : erreurs courantes

Ne stockez pas les JWT dans localStorage : vulnérable aux attaques XSS. Préférez les cookies httpOnly pour le stockage navigateur — JavaScript ne peut pas accéder aux cookies httpOnly.

Vérifiez toujours la signature côté serveur : cet outil décode les JWT pour inspection , il ne vérifie PAS les signatures (cela nécessite la clé secrète du serveur). Ne faites jamais confiance à un contenu JWT sans vérification de signature.

Vérifiez l'expiration (exp) : un JWT sans claim d'expiration est valide indéfiniment. Définissez toujours exp et validez-le à chaque requête.

Attaques par confusion d'algorithme : si votre serveur accepte HS256 et RS256, un attaquant peut créer un jeton HS256 signé avec la clé publique du serveur. Spécifiez toujours un seul algorithme dans la configuration de votre bibliothèque JWT.

Vulnérabilité alg: "none" : les premières bibliothèques JWT acceptaient "alg": "none" et ignoraient la vérification de signature. Configurez toujours votre bibliothèque pour exiger un algorithme spécifique.

Ne mettez jamais de secrets (mots de passe, numéros de carte de crédit) dans les contenus JWT — ils sont lisibles par quiconque possède le jeton.

Questions fréquentes

Qu'est-ce qu'un JWT ?
Un JSON Web Token (JWT, prononcé 'jot') est un format de jeton compact et URL-safe défini dans la RFC 7519. Il se compose de trois parties encodées en Base64URL : un en-tête (algorithme et type), un contenu (claims sur le sujet) et une signature. Les JWT sont couramment utilisés pour l'authentification (bearer tokens), l'autorisation et l'échange d'informations entre services.
Est-il sûr de coller mon JWT ici ?
Cet outil décode entièrement dans votre navigateur — aucune donnée n'est envoyée à un serveur. Cependant, ne collez jamais de JWT de production contenant des sessions actives ou des données sensibles dans un outil en ligne. Utilisez des tokens de dev/test ici. Si un token de production est accidentellement collé, révoquez-le immédiatement.
Que sont les claims exp, iat et nbf ?
Ce sont des noms de claims enregistrés définis dans la RFC 7519 : exp (expiration) — le token ne doit pas être accepté après ce timestamp Unix. iat (émis à) — quand le token a été créé. nbf (pas avant) — le token ne doit pas être accepté avant ce timestamp. Les trois sont des valeurs NumericDate (secondes Unix).
Quelle est la différence entre HS256 et RS256 ?
HS256 (HMAC-SHA256) est un algorithme symétrique — la même clé secrète est utilisée pour signer et vérifier le token. RS256 (RSA-SHA256) est asymétrique — une clé privée signe le token et une clé publique le vérifie. RS256 est préféré dans les systèmes distribués car la partie vérificatrice n'a jamais besoin de la clé privée. Cet outil ne supporte que la vérification HS256.
Où est documentée la spécification JWT ?
La spécification JWT est la RFC 7519, publiée par l'IETF en mai 2015, disponible sur rfc-editor.org/rfc/rfc7519. Les algorithmes de signature sont définis dans la RFC 7518 (JWA). La famille complète de standards s'appelle JOSE (JSON Object Signing and Encryption) et comprend les RFC 7515 (JWS), 7516 (JWE), 7517 (JWK) et 7518 (JWA).
Est-il sûr de décoder un JWT dans le navigateur ?
Décoder un JWT (lire le contenu) est toujours sûr — le décodage Base64URL est une opération réversible sans implications de sécurité. Ce qui n'est PAS sûr, c'est de faire confiance au contenu décodé sans vérification de signature côté serveur. Cet outil décode les JWT à des fins de débogage et d'inspection. Pour les applications en production, la vérification de la signature doit se faire sur le serveur avec la clé secrète ou publique appropriée.
Quelle doit être la durée de validité d'un JWT ?
Les jetons d'accès doivent avoir une courte durée de vie : 5 à 60 minutes est typique. Les jetons de rafraîchissement (si utilisés) peuvent être plus longs : 1 à 30 jours, avec rotation à chaque utilisation. Une expiration plus longue = une fenêtre de sécurité plus grande si un jeton est volé. Pratique courante : jeton d'accès à courte durée de vie + jeton de rafraîchissement à longue durée de vie stocké dans un cookie httpOnly. Si un jeton ne contient pas de claims sensibles, une expiration plus longue sacrifie la sécurité pour la commodité.

Par Bam's Thinkery — Mis à jour le