Skip to content

Décodeur JWT

Décodez des jetons JWT en ligne avec notre décodeur JWT gratuit. Inspectez en-tête, charge utile, signature, expiration et revendications. 100 % navigateur — votre jeton ne quitte jamais votre appareil. Sans inscription ni suivi.

Sans pistage Fonctionne dans le navigateur Gratuit
Jeton JWT
Vérifié pour la conformité RFC 7519 et les garanties de confidentialité — Équipe sécurité Go Tools · 22 avr. 2026

Qu'est-ce qu'un JWT ?

Un JSON Web Token, ou JWT (prononcé « jot »), est un format de jeton compact et sûr pour les URL destiné à transporter des réclamations entre deux parties. Il est défini dans la RFC 7519 et constitue le format d'identification dominant utilisé par les jetons d'accès OAuth 2.0, les jetons ID OpenID Connect, les clés d'API des fournisseurs d'authentification modernes (Auth0, Okta, Clerk, Supabase, Firebase) et les jetons inter-services dans les architectures microservices.

« JSON Web Token (JWT) est un format compact de représentation de réclamations destiné aux environnements à espace contraint comme les en-têtes HTTP Authorization et les paramètres de requête URI. » — RFC 7519, section 1

Un JWT est constitué de trois objets JSON encodés en Base64URL et joints par des points : header.payload.signature. L'en-tête décrit comment le jeton est signé (la réclamation alg — par exemple, HS256 ou RS256 — et la réclamation typ, généralement « JWT »). La charge utile transporte les réclamations : les réclamations enregistrées comme iss, sub, aud, exp, iat, plus les réclamations personnalisées dont l'émetteur a besoin (role, scope, email, identifiant de tenant). La signature est une preuve cryptographique, calculée sur l'en-tête et la charge utile avec le secret ou la clé privée de l'émetteur, qui permet au destinataire de détecter toute altération.

Fondamentalement, un JWT est encodé, pas chiffré. Quiconque possède le jeton peut lire sa charge utile — le décodage est simplement du Base64URL et de l'analyse JSON. La garantie de sécurité vient de la signature : un attaquant peut lire un JWT, mais ne peut pas produire un JWT différent qui passe la vérification de signature sans la clé de signature. C'est pourquoi les JWT peuvent être transmis sur le réseau en toute sécurité, mais ne doivent pas être remplis de secrets.

Un décodeur JWT vous montre exactement ce que contient un jeton — algorithme, réclamations, expiration — sans toucher à la signature. C'est le moyen le plus rapide de répondre à « ce jeton est-il expiré ? », « quel rôle cet utilisateur a-t-il ? », « quel émetteur a émis ce jeton ? » ou « s'agit-il d'un jeton alg:none que je devrais rejeter ? ». Tout le décodage dans cet outil s'exécute localement dans votre navigateur, donc coller un jeton de production actif est sûr.

Le travail avec les JWT se combine souvent à d'autres outils pour développeurs. Vous pourriez avoir besoin de décoder un segment encodé en Base64URL lors du débogage d'un jeton malformé, de décoder-URL un en-tête Authorization après l'avoir capturé depuis un proxy, ou de convertir manuellement la réclamation exp en date lisible. Pour une présentation plus approfondie sur la signature, la vérification et la rotation des JWT en production, consultez notre guide sur les fondamentaux de Base64 — Base64URL est la fondation sur laquelle tout JWT est construit.

// Decode a JWT in the browser — header & payload only
function decodeJwt(token) {
  const [h, p, s] = token.split('.');
  const pad = (seg) => seg + '==='.slice((seg.length + 3) % 4);
  const decode = (seg) => JSON.parse(
    atob(pad(seg).replace(/-/g, '+').replace(/_/g, '/'))
  );
  return { header: decode(h), payload: decode(p), signature: s };
}

const { header, payload } = decodeJwt(token);
console.log(header);   // → { alg: 'HS256', typ: 'JWT' }
console.log(payload);  // → { sub: 'user_123', exp: 1999999999, ... }

// Expiration check
const expired = payload.exp * 1000 < Date.now();

Fonctionnalités clés

Décoder JWT instantanément

Collez et voyez le JWT décodé en temps réel — en-tête, charge utile et signature analysés à la volée. Pas de bouton Décoder, pas d'aller-retour vers un serveur.

Détection d'expiration

Lit automatiquement la réclamation exp et affiche un badge rouge lorsque le jeton est expiré, avec la date d'expiration exacte dans votre fuseau horaire local.

Indépendant de l'algorithme

Décode tous les algorithmes JWS — HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA et alg:none.

100 % local

Le décodage s'exécute dans votre navigateur via atob et JSON.parse natifs. Votre jeton n'est jamais téléversé — sûr pour les informations d'identification de production.

Affichage conscient des réclamations

Met en évidence les réclamations enregistrées par la RFC 7519 (iat, exp, nbf, iss, aud, sub, jti) afin que vous puissiez repérer les problèmes d'authentification d'un coup d'œil.

Copie en un clic

Copiez le JSON de l'en-tête, le JSON de la charge utile ou la signature brute dans votre presse-papiers en un seul clic — parfait pour les rapports de bug et les tests.

Exemples

Jeton HS256 (valide)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxOTk5OTk5OTk5fQ.4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0
{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1715000000,
  "exp": 1999999999
}

Jeton signé HMAC-SHA256 avec un sujet, un rôle et une expiration future — la configuration JWT la plus courante pour l'authentification de session.

Jeton RS256 (expiré)

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleS0yMDI1LTAxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJzdWIiOiI5MDA4NzE2NSIsImlhdCI6MTYwMDAwMDAwMCwiZXhwIjoxNjAwMDAzNjAwLCJzY29wZSI6InJlYWQ6dXNlciB3cml0ZTpwb3N0In0.signature_placeholder
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2025-01"
}

{
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "sub": "90087165",
  "iat": 1600000000,
  "exp": 1600003600,
  "scope": "read:user write:post"
}

Jeton d'accès de style OAuth signé avec RSA — notez le kid (identifiant de clé) dans l'en-tête et la réclamation exp indiquant que le jeton est déjà expiré.

Jeton ID OIDC

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJzdWIiOiIxMTA1MDIyNTExNTU4OTkwNzY2Mzk1IiwiYXpwIjoiY2xpZW50LWlkIiwiYXVkIjoiY2xpZW50LWlkIiwiZW1haWwiOiJhbGljZUBleGFtcGxlLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OSwibm9uY2UiOiJhYmMxMjMifQ.signature
{
  "alg": "ES256",
  "typ": "JWT"
}

{
  "iss": "https://accounts.google.com",
  "sub": "110502251155899076639",
  "azp": "client-id",
  "aud": "client-id",
  "email": "alice@example.com",
  "email_verified": true,
  "iat": 1715000000,
  "exp": 1999999999,
  "nonce": "abc123"
}

Jeton ID OpenID Connect avec signature ECDSA, réclamations d'e-mail, et un nonce pour la protection contre les attaques par rejeu.

Jeton alg:none (non signé)

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZWJ1Zy11c2VyIiwiaWF0IjoxNzE1MDAwMDAwfQ.
{
  "alg": "none",
  "typ": "JWT"
}

{
  "sub": "debug-user",
  "iat": 1715000000
}

Jeton non signé avec alg:none. Accepter ce type de jeton en production est une vulnérabilité JWT classique — rejetez toujours alg:none côté serveur.

Comment utiliser

  1. 1

    Collez votre JWT à décoder

    Collez le jeton complet à décoder — y compris les trois segments séparés par des points — dans la zone de saisie. Le décodeur s'exécute instantanément dans votre navigateur ; vous n'avez pas besoin de cliquer sur un bouton.

  2. 2

    Lisez l'en-tête, la charge utile et le statut décodés

    Lisez l'algorithme et le type de jeton dans l'en-tête décodé, les réclamations dans la charge utile décodée, et les puces d'expiration / d'émission en haut. Un jeton expiré est signalé en rouge.

  3. 3

    Copiez la sortie décodée

    Utilisez le bouton Copier de chaque panneau pour copier le JSON de l'en-tête décodé, le JSON de la charge utile décodée ou la signature brute. Votre jeton n'a jamais été envoyé nulle part — le décodage s'est effectué localement dans votre navigateur.

Common Errors

Accepter alg:none

Un JWT non signé peut être forgé par n'importe qui. N'autorisez jamais alg:none en production — passez toujours une liste d'algorithmes explicite à votre appel de vérification.

✗ Incorrect
jwt.verify(token, secret)  // library default may allow 'none'
✓ Correct
jwt.verify(token, secret, { algorithms: ['RS256'] })

Absence de réclamation exp

Un JWT sans exp vit éternellement. Si un jeton fuit, il n'y a pas de point de révocation naturel. Définissez toujours une expiration appropriée au type de jeton.

✗ Incorrect
{ "sub": "user_123", "role": "admin" }  // no exp
✓ Correct
{ "sub": "user_123", "role": "admin", "exp": 1715003600 }

Stocker des secrets dans la charge utile

Les charges utiles JWT ne sont pas chiffrées — quiconque possède le jeton peut les lire. Ne mettez jamais de mots de passe, de clés d'API ou d'informations personnelles non tronquées dans une charge utile JWT.

✗ Incorrect
{ "sub": "user_123", "password": "hunter2" }
✓ Correct
{ "sub": "user_123", "role": "admin" }  // payload stays minimal

Cas d'usage courants

Décoder les jetons Authorization Bearer
Décodez les jetons JWT des en-têtes Authorization: Bearer pour vérifier les réclamations, l'audience et l'expiration que votre backend reçoit.
Décoder les jetons OAuth 2.0 et OIDC
Décodez les jetons d'accès et les jetons ID retournés par les serveurs d'autorisation (Auth0, Okta, Google, Keycloak) lors de l'intégration OAuth 2.0 et OpenID Connect.
Diagnostic de session expirée
Confirmez en une seconde si un jeton rejeté est expiré, utilise la mauvaise audience ou souffre d'un problème de dérive d'horloge.
Vérifications de rotation de clés
Lisez le kid (identifiant de clé) dans l'en-tête pour vérifier que votre rotation JWKS émet des jetons signés avec la clé attendue.
Revues de sécurité
Repérez les jetons signés avec alg:none, sans exp, ou divulguant des informations personnelles dans la charge utile pendant la revue de code et les pentests.
Inspection de jetons microservices
Décodez les jetons de service à service à l'intérieur d'un maillage pour voir quels scopes et quel sujet un appel en aval autorise.

Détails techniques

Conforme à la RFC 7519
Gère les jetons JWS conformes à la RFC 7519 (JWT), à la RFC 7515 (JWS) et à la RFC 7518 (JWA) — tous les algorithmes enregistrés sont pris en charge pour le décodage.
Décodage Base64URL
Utilise l'alphabet Base64 sûr pour les URL (- et _ à la place de + et /) défini dans la RFC 4648, avec une analyse tolérante au remplissage.
Natif au navigateur, zéro dépendance
Construit sur atob, TextDecoder et JSON.parse du navigateur — aucune bibliothèque externe, aucun appel réseau, aucune télémétrie.

Bonnes pratiques

Ne jamais faire confiance sans vérifier
Un décodeur affiche les réclamations ; il ne les prouve pas. Vérifiez toujours la signature côté serveur contre la clé de l'émetteur avant de faire confiance à toute réclamation.
Rejeter alg:none en production
Configurez votre bibliothèque JWT avec une liste d'autorisation explicite d'algorithmes. N'acceptez jamais alg:none, et soyez méfiant face aux incohérences d'alg lors de la rotation de clés.
Gardez les charges utiles minces
Placez des identifiants et des réclamations à courte durée de vie dans le JWT ; gardez les données volumineuses derrière un identifiant de session opaque. Les gros jetons coûtent de la bande passante à chaque requête.

Questions fréquentes

Comment décoder un jeton JWT en ligne ?
Collez le JWT complet — les trois segments séparés par des points (header.payload.signature) — dans le décodeur ci-dessus. Le décodage se fait instantanément dans votre navigateur : l'en-tête et la charge utile sont décodés en Base64URL en JSON lisible, et la signature est affichée sous forme de chaîne brute. Une ligne de statut fait apparaître l'algorithme de signature, l'heure d'émission et l'expiration, afin que vous puissiez repérer un jeton expiré d'un coup d'œil. Pour décoder un JWT manuellement, séparez le jeton par les points, décodez les deux premiers segments en Base64URL et analysez-les en JSON — quiconque possède le jeton peut lire ses réclamations car la charge utile est encodée, pas chiffrée. Ce décodeur peut être utilisé en toute sécurité avec des jetons de production car rien ne quitte jamais votre appareil : aucune requête réseau, aucune journalisation, aucun suivi.
Qu'est-ce qu'un JWT (JSON Web Token) ?
Un JSON Web Token (JWT) est une informations d'identification compacte et sûre pour les URL qui transporte des réclamations entre deux parties. Défini dans la RFC 7519, il se compose de trois sections encodées en Base64URL et séparées par des points : l'en-tête (algorithme et type de jeton), la charge utile (réclamations — données sur l'utilisateur et sur le jeton lui-même) et la signature (une preuve cryptographique que le jeton a été émis par une partie de confiance). Les JWT sont la manière standard de représenter les jetons d'accès dans OAuth 2.0 et les jetons ID dans OpenID Connect.
Mon jeton est-il en sécurité avec ce décodeur JWT ?
Oui. Tout le décodage s'exécute dans votre navigateur avec du JavaScript natif (atob et TextDecoder). Votre jeton n'est jamais envoyé à un serveur, jamais journalisé, jamais stocké, et jamais utilisé à des fins analytiques. Il n'y a ni cookies ni suivi. C'est important car les JWT peuvent contenir des jetons d'accès actifs — les coller dans un débogueur distant équivaudrait à remettre une information d'identification. Notre outil peut être utilisé en toute sécurité avec des jetons de production.
Comment fonctionne un décodeur JWT ?
Un décodeur JWT divise le jeton par les points en trois parties, décode l'en-tête et la charge utile en Base64URL et les analyse en tant que JSON. La signature est laissée sous forme de chaîne Base64URL opaque car la vérifier nécessite le secret ou la clé publique de l'émetteur — ce qu'un décodeur côté client ne peut pas faire de manière sûre. Cela signifie que le décodage est instantané et révèle les réclamations, mais vous devez vérifier la signature côté serveur avec la bonne clé avant de faire confiance à quoi que ce soit à l'intérieur.
Cet outil peut-il vérifier la signature d'un JWT ?
Non, et c'est intentionnel. La vérification de la signature nécessite le secret de l'émetteur (pour HMAC) ou la clé publique (pour RSA/ECDSA/EdDSA), ce qui ne devrait jamais être collé dans un outil web public. La vérification doit avoir lieu sur votre serveur, dans votre middleware d'authentification, ou à l'intérieur d'un SDK qui a accès à votre point d'accès JWKS. Ce décodeur sert à inspecter ce qu'un jeton déclare — il n'implique pas que le jeton soit authentique ou non altéré.
Que sont iat, exp, nbf, iss, aud, sub et jti ?
Ce sont les réclamations enregistrées de la RFC 7519. iat (issued at — émis à) est l'horodatage Unix de la création du jeton. exp (expiration) est le moment où le jeton cesse d'être valide — cet outil le convertit en une date lisible et marque le jeton comme expiré si exp est dans le passé. nbf (not before — pas avant) est le premier moment où le jeton peut être utilisé. iss (issuer — émetteur) identifie qui a créé le jeton. aud (audience) nomme le destinataire prévu. sub (subject — sujet) identifie le principal — généralement un identifiant utilisateur. jti est un identifiant unique de jeton utilisé pour empêcher le rejeu. Les réclamations spécifiques à l'application (role, scope, email, name) cohabitent avec celles-ci.
Mon JWT est expiré — pourquoi le décodeur le décode-t-il quand même ?
Décoder n'est pas la même chose que valider. Un décodeur JWT lit le contenu quelle que soit l'expiration, ce qui vous permet d'inspecter un jeton expiré ou autrement invalide pour comprendre pourquoi il a été rejeté. Le badge « Expiré » de cet outil compare la réclamation exp à votre horloge locale et signale les jetons dont exp est dans le passé. Un vrai serveur d'authentification rejetterait purement et simplement le jeton — mais un décodeur qui refuserait de montrer les jetons expirés serait inutile pour le débogage.
Quelle est la différence entre JWT, JWS et JWE ?
JWT est le concept général — un objet JSON encodé sous forme de jeton compact. JWS (RFC 7515) est un JWT signé : la charge utile est lisible par quiconque la décode, et une signature prouve qu'elle n'a pas été altérée. C'est de loin le JWT le plus courant que vous rencontrerez. JWE (RFC 7516) est un JWT chiffré : la charge utile elle-même est du texte chiffré et ne peut pas être décodée sans la clé de déchiffrement. Cet outil décode les jetons JWS. Un jeton JWE ne décodera que son en-tête — la charge utile chiffrée n'est pas lisible sans la clé.
Pourquoi alg:none est-il dangereux ?
Un JWT avec alg:none n'a pas de signature — n'importe qui peut en construire un, en prétendant être n'importe quel utilisateur. Les premières bibliothèques JWT acceptaient alg:none par défaut, conduisant à une classe bien connue de contournements d'authentification où un attaquant pouvait retirer la signature, définir alg sur none et forger un jeton d'administrateur. Toute bibliothèque JWT mature rejette désormais alg:none sauf autorisation explicite, et vous ne devez jamais l'accepter pour des requêtes authentifiées. Ce décodeur vous affichera quand même un jeton alg:none, car en inspecter un pendant le débogage est légitime — mais traitez tout jeton de ce type reçu en production comme hostile.
Quels algorithmes ce décodeur JWT prend-il en charge ?
Le décodage de l'en-tête et de la charge utile fonctionne pour tous les algorithmes, car le décodage n'a besoin que de Base64URL et d'analyse JSON — il est indépendant de l'algorithme. L'outil lit correctement les jetons signés avec HS256, HS384, HS512 (HMAC), RS256, RS384, RS512 (RSA + SHA), PS256, PS384, PS512 (RSA-PSS), ES256, ES384, ES512 (ECDSA), EdDSA (Ed25519/Ed448) et les jetons non signés (alg:none). Seule la vérification de la signature est spécifique à l'algorithme, et cet outil n'effectue pas de vérification.
Devrais-je stocker les JWT dans localStorage ou dans des cookies ?
Préférez les cookies HttpOnly, Secure, SameSite=Strict pour les jetons de session. Un jeton dans localStorage est lisible par tout JavaScript qui s'exécute sur la page, donc une seule vulnérabilité XSS fait fuiter toutes les sessions actives. Les cookies HttpOnly sont invisibles pour JavaScript, ce qui réduit le rayon d'impact d'une XSS à ce qu'un attaquant peut faire au sein d'une page active — et non à un jeton volé qu'il pourrait rejouer pendant des jours. Si vous devez utiliser localStorage (par exemple pour des applications multi-domaines), gardez les durées de vie des jetons d'accès courtes (minutes, pas heures) et utilisez un jeton de rafraîchissement distinct dans un cookie HttpOnly.
Comment décoder un JWT en Node.js, Python ou Go ?
Node.js : jsonwebtoken.decode(token) pour la lecture seule, jsonwebtoken.verify(token, key) pour la vérification. Python : PyJWT.decode(token, options={'verify_signature': False}) pour lire, passez une clé pour vérifier. Go : jwt.ParseUnverified(token, claims) pour la lecture seule, jwt.Parse(token, keyFunc) pour la vérification. Dans tous les langages, ne vérifiez jamais avec options={'verify_signature': False} en code de production — c'est ce que cet outil web fait délibérément pour le débogage, et ce n'est sûr que lorsque vous inspectez, pas lorsque vous authentifiez.
Quelle est la taille maximale d'un JWT ?
Le standard JWT n'impose pas de limite stricte, mais les en-têtes de la plupart des serveurs web sont par défaut autour de 8 Ko. Gardez les jetons sous 4 Ko afin qu'ils tiennent confortablement dans les en-têtes Authorization et les cookies. Si votre jeton est plus grand que cela, vous mettez probablement trop de réclamations dans la charge utile — déplacez les données volumineuses derrière un identifiant de session opaque et récupérez-les depuis votre backend si nécessaire. Des JWT gonflés deviennent aussi coûteux à chaque requête car ils sont envoyés avec chaque appel d'API.
J'ai collé mon jeton et j'ai obtenu « Format JWT invalide » — quel est le problème ?
Un JWT valide comporte exactement trois parties séparées par des points : header.payload.signature. Causes courantes : (1) vous avez copié accidentellement uniquement le segment de charge utile, (2) des espaces ou des retours à la ligne ont été collés au milieu, (3) le jeton a été tronqué pendant le transit (courant avec le retour à la ligne du terminal), (4) le jeton est un JWE dont le format est header.encryptedKey.iv.ciphertext.tag (cinq segments), ou (5) le jeton a été encodé-URL et vous devez d'abord le décoder-URL. Vérifiez la valeur brute retournée par votre API — la plupart des éditeurs affichent les caractères invisibles au survol.
Peut-on décoder un JWT sans la clé secrète ?
Oui — l'en-tête et la charge utile sont encodés en Base64URL, pas chiffrés. Quiconque possède le jeton peut lire ses réclamations sans aucune clé. C'est voulu : la charge utile est censée être lisible afin que le destinataire puisse prendre des décisions d'autorisation à partir d'elle. La clé secrète ou publique n'est requise que pour vérifier que le jeton n'a pas été altéré. C'est pourquoi vous ne devez jamais mettre de données sensibles (mots de passe, clés privées, informations personnelles au-delà de ce que le destinataire connaît déjà) à l'intérieur d'une charge utile JWT.
Mon JWT fonctionne dans Postman mais mon backend le rejette — comment déboguer ?
Décodez le jeton ici et vérifiez : (1) exp — est-il dans le futur par rapport à l'horloge du serveur ? La dérive d'horloge serveur est une cause fréquente. (2) iss / aud — correspondent-ils exactement à ce que votre backend attend ? Un décalage sur aud est le faux-négatif le plus courant. (3) alg — votre code de vérification autorise-t-il cet algorithme ? Un jeton HS256 échouera face à une bibliothèque configurée pour RS256 uniquement. (4) kid — si vous utilisez la rotation de clés, l'identifiant de clé dans l'en-tête est-il présent dans votre JWKS ? (5) signature — avez-vous collé le bon secret / la bonne clé publique ? Ce décodeur fait apparaître (1), (2), (3) et (4) dans les vues d'en-tête et de charge utile afin que vous puissiez les éliminer rapidement.