Décodeur JWT

Décoder et inspecter les JSON Web Tokens

Essayer un exemple

Token JWT

Fonctionne localement · Sûr pour coller des secrets
Essayez aussi :Encodeur JWT

Qu'est-ce qu'un JWT (JSON Web Token) ?

Un JSON Web Token (JWT) est un format de token compact et sûr pour les URL, défini dans la RFC 7519. Il encode un ensemble de claims sous forme d'objet JSON, puis le signe — et éventuellement le chiffre — afin que le destinataire puisse vérifier que les données n'ont pas été altérées. Les JWT sont le standard de facto pour l'authentification sans état dans les REST APIs, les systèmes d'authentification unique et l'autorisation de microservices.

Anatomie d'un JWT : En-tête · Payload · Signature

Tout JWT est composé de trois segments encodés en base64url séparés par des points. L'en-tête et le payload sont du JSON brut — lisibles par n'importe qui — tandis que la signature est une valeur cryptographique qui ne peut être vérifiée qu'avec la bonne clé.

Token encodé

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

En-têtePayloadSignature
En-tête
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

Pourquoi utiliser un décodeur JWT ?

Les JWT bruts ressemblent à du texte aléatoire. Cet outil affiche instantanément l'en-tête et le payload sous forme de JSON formaté pour inspecter les claims, vérifier les dates d'expiration et auditer les choix d'algorithmes sans écrire une seule ligne de code.

🔍
Inspection instantanée des claims
Visualisez chaque claim dans le payload — sub, iss, aud, exp, rôles personnalisés, permissions — formaté et lisible en un seul clic.
🔓
Aucune clé secrète requise
L'en-tête et le payload sont publics ; seule la signature nécessite le secret. Cet outil décode les deux sans votre clé de signature.
⏱️
Analyse des expirations et horodatages
Les horodatages Unix (exp, iat, nbf) sont automatiquement convertis en dates lisibles pour vérifier instantanément si un token a expiré.
🔒
Fonctionne entièrement dans votre navigateur
Tout est traité localement — aucune donnée de token n'est envoyée à un serveur. Sûr à utiliser avec des tokens de production lors du débogage.

Référence des claims JWT standard

La RFC 7519 définit sept noms de claims enregistrés. Ils ne sont pas obligatoires, mais leur utilisation est fortement recommandée pour l'interopérabilité. Vous pouvez ajouter n'importe quel claim personnalisé au payload.

ClaimDescriptionType
issÉmetteurIdentifie qui a émis le token — par ex. l'URL de votre serveur d'authentification ou le nom de l'application.string
subSujetIdentifie le principal concerné par le JWT — généralement un ID utilisateur ou un compte de service.string
audAudienceIdentifie les destinataires prévus. La partie réceptrice doit vérifier que cela correspond à son identifiant.string | string[]
expTemps d'expirationHorodatage Unix après lequel le token ne doit plus être accepté. Toujours définir cette valeur pour limiter les dégâts en cas de vol.number
nbfPas avantHorodatage Unix avant lequel le token ne doit pas être accepté. Utile pour planifier des tokens à date future.number
iatÉmis àHorodatage Unix auquel le token a été émis. Utilisé pour calculer l'âge du token.number
jtiJWT IDUn identifiant unique pour le token. Permet la révocation en stockant et vérifiant les valeurs JTI utilisées côté serveur.string

Algorithmes de signature JWT

Le claim d'en-tête alg déclare quel algorithme a signé le token. Le choix affecte la sécurité, les performances et la capacité des services tiers à vérifier les tokens sans la clé privée.

AlgorithmeFamilleType de cléNotes
HS256HMACSymmetricLe plus courant. Secret partagé — quiconque possède le secret peut signer et vérifier.
HS384HMACSymmetricVariante HMAC plus robuste ; coût de performance modéré.
HS512HMACSymmetricVariante HMAC la plus forte.
RS256RSAAsymmetricAlgorithme asymétrique le plus utilisé (Google, Auth0, Okta). La clé publique vérifie sans la clé privée.
RS384RSAAsymmetricVariante RS à sécurité renforcée.
RS512RSAAsymmetricVariante RS la plus forte.
ES256ECDSAAsymmetricCourbe elliptique — signatures plus courtes que RSA, populaire sur mobile et IoT.
PS256RSA-PSSAsymmetricRSA-PSS : plus moderne et plus sûr que RS256 basé sur PKCS1v1.5.
noneAucune signature — dangereusement critique. N'acceptez jamais de tokens avec alg: none en production.

Considérations de sécurité

Décoder un JWT est toujours sûr. Faire confiance à un JWT sans vérification appropriée de la signature ne l'est pas. Gardez ces règles à l'esprit chaque fois que vous consommez des tokens dans votre application.

Toujours sûr
  • Décoder et inspecter un JWT dans les outils de développement ou dans cet outil
  • Utiliser exp, iat et nbf pour comprendre la durée de vie du token
  • Journaliser les claims du payload pour le débogage (omettre les PII sensibles)
  • Lire l'en-tête alg pour comprendre comment le token a été signé
À ne jamais faire
  • Faire confiance aux claims du payload sans vérifier la signature côté serveur
  • Accepter des tokens avec alg: none — cela signifie aucune signature du tout
  • Stocker des tokens d'accès dans localStorage dans des applications à haute sécurité (préférer les cookies httpOnly)
  • Définir exp très loin dans le futur pour des tokens portant des permissions sensibles

Cas d'usage courants

Débogage des flux d'authentification
Collez un token depuis l'onglet réseau de votre navigateur pour inspecter les claims, vérifier les rôles intégrés et contrôler l'expiration sans toucher au code de production.
Inspection des tokens tiers
Lisez rapidement les tokens de Google, Auth0, Okta ou Azure AD pour voir quels claims votre fournisseur inclut et les comparer à votre schéma attendu.
Développement et tests d'API
Lors de l'écriture ou du test d'endpoints API, décodez l'en-tête d'autorisation pour confirmer que votre logique de génération de tokens définit les bonnes valeurs pour sub, aud et scope.
Autorisation de microservices
Dans les maillages de services, chaque service valide le JWT de l'appelant en amont. Décodez les tokens pour tracer quel service a émis le token et quelles permissions il revendique.
Support et réponse aux incidents
Lorsqu'un utilisateur signale une erreur d'authentification, décodez son token pour vérifier s'il a expiré, si l'audience est incorrecte ou si un claim requis est manquant.
Audit de sécurité
Auditez l'utilisation des JWT à travers les services en vérifiant les choix d'algorithmes, les fenêtres d'expiration et si des données sensibles sont accidentellement stockées dans le payload non chiffré.

Décoder un JWT en code

L'en-tête et le payload sont encodés en base64url — il suffit d'inverser l'encodage. Base64url remplace + par - et / par _, et omet le rembourrage =. Seule la signature nécessite la clé secrète.

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

Questions fréquentes

Puis-je décoder un JWT sans la clé secrète ?
Oui. L'en-tête et le payload d'un JWT sont simplement du JSON encodé en base64url — pas chiffré. N'importe qui peut les décoder et les lire. Le secret (ou la clé privée pour les algorithmes RS/ES) n'est nécessaire que pour vérifier la signature, confirmant que le token n'a pas été altéré.
Décoder un JWT signifie-t-il que la signature est vérifiée ?
Non. Décoder ne fait que lire les claims. La vérification est une étape distincte qui contrôle la signature cryptographique avec la bonne clé. Vérifiez toujours la signature avant de faire confiance à des claims dans votre application.
Quelle est la différence entre HS256 et RS256 ?
HS256 utilise un secret symétrique unique partagé entre l'émetteur et le vérificateur — quiconque possède le secret peut créer et vérifier des tokens. RS256 utilise une paire de clés asymétriques : la clé privée signe, la clé publique vérifie. Avec RS256, vous pouvez distribuer la clé publique pour que des services externes puissent vérifier les tokens sans pouvoir les forger.
Pourquoi le décodage base64 échoue-t-il parfois ?
Les JWT utilisent l'encodage base64url, qui utilise - au lieu de + et _ au lieu de /, et omet les caractères de rembourrage =. Les décodeurs base64 standard nécessitent + et / et peuvent nécessiter un rembourrage. Ajoutez le rembourrage (multiple de 4 avec =) et échangez les caractères avant de décoder manuellement.
Est-il sûr de coller un JWT de production dans cet outil ?
Oui — cet outil fonctionne entièrement dans votre navigateur et n'envoie aucune donnée à un serveur. Cependant, soyez attentif à qui peut voir votre écran ou votre historique de navigation. Pour les tokens très sensibles, décodez-les localement dans votre terminal.
Que signifie alg: none et est-ce dangereux ?
alg: none signifie que le token n'a pas de signature cryptographique — n'importe qui peut créer un token avec des claims arbitraires et définir alg sur none. Certaines bibliothèques JWT anciennes acceptaient ces tokens, créant une vulnérabilité critique. Une bibliothèque JWT sécurisée rejette toujours les tokens avec alg: none sauf configuration explicite contraire. Ne désactivez jamais cette vérification.