Gratuit · Sans inscription

Décodeur JWT

Collez un JSON Web Token et inspectez instantanément son header, son payload et ses claims — avec les dates d'expiration traduites en format lisible.

Traité en mémoire — jamais stocké, jamais journalisé, aucun compte requis.

Comment un JWT est structuré

Un JSON Web Token se compose de trois segments encodés en base64url séparés par des points : header.payload.signature. Le header déclare l'algorithme de signature (alg) et le type de token ; le payload porte les claims — le sujet du token (sub), son émetteur (iss) et son expiration (exp).

Le base64url est un encodage, pas un chiffrement : quiconque détient un JWT peut lire son contenu — c'est exactement ce que fait cet outil. Ne mettez jamais de secrets dans un payload JWT. Ce qui rend un JWT digne de confiance, c'est sa signature, que seul le détenteur de la clé peut produire.

Ce décodeur ne vérifie volontairement pas les signatures — cela nécessite le secret ou la clé publique et relève de votre backend. Utilisez-le pour comprendre pourquoi un token est rejeté : mauvaise audience, exp dépassé, décalage d'horloge sur nbf, ou algorithme inattendu.

Votre API rejette des tokens à 3 h du matin ? Sachez-le en premier

ContinuumNexus surveille vos endpoints authentifiés en continu et vous alerte dès qu'ils commencent à échouer.

Surveiller gratuitement Découvrir les fonctionnalités

Questions fréquentes

Est-ce sûr de coller un JWT ici ?
Votre token est décodé en mémoire et n'est jamais stocké, journalisé ni partagé. Cela dit, traitez les tokens de production comme des mots de passe : préférez des tokens expirés ou de test pour déboguer, et faites tourner tout secret que vous pensez exposé.
Cet outil vérifie-t-il la signature du JWT ?
Non — la vérification nécessite le secret de signature (HS256) ou la clé publique de l'émetteur (RS256/ES256) et doit se faire côté serveur. Cet outil décode le header et le payload pour inspecter les claims et l'expiration.
Pourquoi mon token apparemment valide est-il rejeté par l'API ?
Les suspects habituels : le claim exp est dans le passé, le claim nbf est dans le futur (décalage d'horloge), les claims aud ou iss ne correspondent pas à ce que l'API attend, ou l'API attend un autre algorithme de signature que celui du header.
Les JWT sont-ils chiffrés ?
Les JWT signés standards (JWS) ne sont pas chiffrés — le payload est lisible par tous. Les JWT chiffrés (JWE) existent mais sont plus rares ; ils comportent cinq segments au lieu de trois. Cet outil gère le format signé courant.
Quels sont les claims JWT standards ?
Les claims enregistrés sont iss (émetteur), sub (sujet), aud (audience), exp (expiration), nbf (pas avant), iat (émis le) et jti (identifiant unique). Tout le reste est un claim personnalisé défini par votre fournisseur d'identité ou votre application.