Décodeur JWT

Décoder un JWT

Inspectez le contenu d’un token JWT sans chercher sa clé : header, payload et dates exp, iat, nbf en UTC. Collez le token ou sa valeur Bearer pour comprendre une requête d’authentification.

Décodeur JWTDécodage dans le navigateur
Collez un JWT ou une valeur Authorization: Bearer. Cet outil ne transmet pas le token à une API de décodage et ne conserve pas la saisie.
Charger un exemple
Décodé uniquement · signature non vérifiée

Des claims lisibles peuvent être falsifiés. Vérifiez la signature et les exigences de votre application avant de faire confiance au token.

01 Header

Algorithme et métadonnées

{
  "alg": "HS256",
  "typ": "JWT"
}

02 Payload

Claims contenus dans le token

{
  "sub": "demo-user",
  "iss": "https://example.com",
  "aud": "demo-api",
  "iat": 1704067200,
  "nbf": 1704067200,
  "exp": 1704070800
}

Dates du token UTC

Comparaison avec l’horloge de votre appareil, sans marge de décalage. Ces indications ne prouvent pas la validité du token.

ClaimDate en UTCComparaison avec l’horloge
iatÉmis le2024-01-01T00:00:00.000ZLecture de l’horloge…
nbfUtilisable à partir du2024-01-01T00:00:00.000ZLecture de l’horloge…
expExpiration2024-01-01T01:00:00.000ZLecture de l’horloge…

03 Signature

Algorithme déclaré: HS256 · 11 octets · non vérifiée

cGxhY2Vob2xkZXI

Un token lisible peut quand même être refusé

Lorsqu’une API renvoie une erreur d’authentification, commencez par vérifier à qui le token est destiné. aud désigne le destinataire attendu et peut contenir une chaîne ou un tableau de chaînes. iss indique l’émetteur ; sub, le sujet du token.

Ces claims décrivent ce que le token affirme. Leur présence ne prouve pas leur authenticité. Les champs obligatoires et les valeurs acceptées dépendent de votre application et du protocole utilisé : une date future ne suffit pas à autoriser une requête.

Lire les trois segments d’un JWT

Un JWT signé courant suit le format header.payload.signature. Le header et le payload sont des objets JSON en UTF-8, encodés en Base64url. La signature contient des octets de signature ou de MAC, et non un troisième document JSON.

Collez le token seul ou précédé de Bearer ou Authorization: Bearer. N’incluez pas la requête HTTP complète. Les deux objets JSON sont présentés séparément et peuvent être copiés. La représentation d’origine des nombres est conservée, notamment pour les grands identifiants entiers.

Comprendre exp, nbf et iat

exp fixe l’expiration, nbf le début d’utilisation autorisé et iat la date d’émission. Ces valeurs NumericDate sont exprimées en secondes depuis l’époque Unix. Par exemple, 1704067200 correspond au 1er janvier 2024 à 00 h 00 UTC, et non à une valeur JavaScript en millisecondes.

La comparaison utilise l’horloge de votre appareil, sans marge pour un éventuel décalage. Elle sert au diagnostic, pas à valider le token. Une date d’émission future mérite d’être examinée, mais la décision de refus appartient aux règles de l’application.

Décoder, déchiffrer et vérifier : trois opérations distinctes

Base64url est un encodage, pas un chiffrement. Il n’est donc pas nécessaire de connaître le secret pour lire un JWT signé. Vérifier sa provenance exige en revanche une clé de confiance, des algorithmes autorisés explicitement et le contrôle des claims attendus. Ne laissez pas le seul alg du token définir la politique de confiance.

Ce décodeur ne consulte aucune URL de clé et n’utilise pas de clé intégrée. Il ne déchiffre pas les JWE à cinq segments et ne traite ni les JWT imbriqués ni b64: false. Limites : 50 000 caractères et 64 niveaux JSON. Les clés en double sont refusées pour éviter une interprétation ambiguë.

Trois cas à explorer

Token expiré

Données fictives et signature factice, inutilisables pour s’authentifier.

Revenir au décodeur JWT

Sans signature

Exemple alg: none avec une troisième partie vide.

Revenir au décodeur JWT

Claims Unicode

Texte multilingue et plusieurs destinataires ; signature factice.

Revenir au décodeur JWT

Questions fréquentes

Faut-il fournir un secret pour décoder ?

Non. Pour un JWT compact en trois parties, le header et le payload se lisent en décodant Base64url. Le secret ou la clé publique concerne la vérification cryptographique, que cet outil ne réalise pas.

Pourquoi la signature n’apparaît-elle pas en JSON ?

Elle représente des octets de signature ou de MAC. Le décodeur affiche sa valeur Base64url et sa taille décodée, sans essayer de les interpréter comme du texte.

Que signifie alg: none ?

Il s’agit d’un JWT non sécurisé, sans signature cryptographique. La troisième partie reste présente mais vide : le token se termine donc par un point. Sa lecture ne permet pas de lui faire confiance.

Le contenu est-il conservé ?

La saisie est traitée dans le navigateur, sans envoi à une API de décodage, sans stockage par l’outil et sans ajout à l’URL. Un vrai bearer token peut donner accès à un service ; les exemples fournis sont fictifs.

Que montrent les exemples ?

Le token expiré a un exp au 1er janvier 2024 à 01 h 00 UTC et une signature factice. Le token sans signature utilise alg: none. L’exemple Unicode contient du texte multilingue et un aud multiple, avec une signature factice lui aussi. Aucun n’est utilisable pour s’authentifier.

Pourquoi ma saisie est-elle rejetée ?

Vérifiez les trois segments, les espaces et le remplissage Base64url. Les deux premiers doivent contenir des objets JSON UTF-8. Les clés en double, les signatures vides incompatibles avec alg et les formats mal encodés sont refusés. En cas d’erreur, l’ancien résultat est retiré.

RFC 7519 · RFC 7515 · RFC 8725

Revenir au décodeur JWT