Décodez, vérifiez et signez des JSON Web Tokens dans votre navigateur.

Un JSON Web Token (JWT) est un identifiant compact et compatible avec les URL, composé de trois parties base64url séparées par des points : un header, un payload de revendications (claims) et une signature — écrit sous la forme header.payload.signature. Le header indique l’algorithme de signature, le payload porte des revendications telles que le destinataire du jeton et sa date d’expiration, et la signature permet au destinataire de confirmer que le jeton a été émis par une partie de confiance et qu’il n’a pas été altéré. Les JWT sont largement utilisés comme jetons d’accès et jetons d’identité dans OAuth 2.0 et OpenID Connect.

Non. Le décodage et toute vérification de signature s’exécutent à 100 % côté client dans votre onglet — il n’y a pas de serveur, pas de compte, pas de journalisation et aucune requête réseau. Le jeton que vous collez ainsi que le secret ou la clé publique que vous fournissez restent en mémoire dans cette page et ne sont jamais transmis. Vous pouvez décoder des jetons hors ligne.

Oui, de façon optionnelle et locale. Collez un secret partagé pour un jeton HMAC (HS256 / HS384 / HS512) ou une clé publique pour un jeton asymétrique — RS256–512, PS256–512, ES256–512 ou EdDSA — et l’outil recalcule la signature sur les octets header.payload à l’aide de la Web Crypto API, directement dans votre navigateur, puis indique si elle est valide ou invalide. La clé peut être un bloc PEM « BEGIN PUBLIC KEY », un JWK seul ou un JWKS complet (la bonne clé est choisie d’après le kid du header). Si vous laissez la clé vide, il décode simplement sans vérifier la signature.

Oui. Passez à l’onglet « Encode & sign », modifiez le JSON du header et du payload, choisissez un algorithme et fournissez un secret (pour HS256/384/512) ou une clé privée PKCS8 / un JWK privé (pour RS, PS, ES ou EdDSA). Le jeton est signé en direct dans votre navigateur avec la Web Crypto API — rien n’est généré sur un serveur. Un onglet « Generate keys » permet en outre de créer des secrets HMAC de test et des paires de clés RSA / EC / Ed25519, exportées à la fois en PEM et en JWK.

Les treize algorithmes de signature JWS que les navigateurs savent exécuter nativement : HS256, HS384 et HS512 (HMAC), RS256, RS384 et RS512 (RSASSA-PKCS1-v1_5), PS256, PS384 et PS512 (RSA-PSS), ES256, ES384 et ES512 (ECDSA sur P-256, P-384 et P-521), et EdDSA (Ed25519, dans les navigateurs qui le prennent en charge). Les jetons non signés alg:"none" sont décodés — avec un avertissement — mais jamais créés ici, et ES256K (secp256k1) n’est pas disponible dans la Web Crypto API.

Pour le développement et les tests, oui : les clés proviennent du générateur cryptographiquement sûr de la Web Crypto API, sont créées entièrement sur votre machine et ne sont jamais transmises ni stockées par cette page. Pour la production, générez et conservez plutôt vos clés dans le KMS, le HSM ou le gestionnaire de secrets de votre plateforme — un onglet de navigateur n’offre aucun stockage sécurisé, et tout ce qui s’affiche à l’écran peut se retrouver dans des captures d’écran ou l’historique du presse-papiers.

Ce sont des revendications enregistrées standard exprimées au format NumericDate (secondes écoulées depuis l’epoch Unix). exp (expiration time) est l’instant après lequel le jeton doit être rejeté ; nbf (not before) est l’instant avant lequel il ne doit pas être accepté ; iat (issued at) correspond au moment où le jeton a été créé. Le décodeur convertit chacune en une heure UTC lisible et signale si le jeton est actuellement expiré ou pas encore valide.

Le décodage a lieu uniquement dans votre navigateur, donc rien n’est transmis — mais un JWT reste un identifiant actif. Traitez-le comme un mot de passe : ne collez qu’un jeton que vous contrôlez, privilégiez un jeton à courte durée de vie ou de test, et rappelez-vous que le payload est simplement encodé en base64url, et non chiffré : quiconque détient le jeton peut donc en lire les revendications. Faites tourner ou révoquez un jeton si vous soupçonnez qu’il a été exposé quelque part. Cette prudence vaut doublement pour les chatbots IA : considérez tout jeton collé dans une fenêtre de chat comme exposé, et effectuez-en la rotation.

Les JWT signés standard ne sont pas chiffrés — le header et le payload sont uniquement encodés en base64url, si bien que quiconque possède le jeton peut en lire les revendications sans aucune clé. La signature prouve que le jeton n’a pas été altéré, mais elle n’en masque pas le contenu. Pour cette raison, vous ne devez jamais stocker de mots de passe, de données personnelles ou de secrets dans les revendications d’un JWT.

Oui. La lecture du header et du payload ne nécessite aucune clé, car les données sont seulement encodées en base64url. Le secret ou la clé publique n’est nécessaire que pour vérifier la signature — afin de confirmer que le jeton provient bien de l’émetteur attendu. Ce décodeur vous permet d’inspecter les revendications que vous fournissiez ou non une clé.

Collez le jeton dans le JWT Decoder et regardez la ligne de la revendication exp. L’outil convertit l’horodatage Unix brut en une date UTC lisible et signale automatiquement le jeton comme expiré si l’heure actuelle a dépassé la valeur exp. Les revendications iat (issued at) et nbf (not before) sont également affichées avec leurs dates lisibles.

Non. Le décodage ne fait que révéler le contenu du header et du payload — il ne prouve pas que le jeton est authentique. Pour valider un jeton, vous devez vérifier sa signature à l’aide du secret ou de la clé publique de l’émetteur. Cet outil peut effectuer cette vérification localement dans le navigateur, mais pour les décisions d’autorisation, la signature doit toujours être vérifiée côté serveur avant d’accorder confiance à une quelconque revendication.