Décodez n'importe quel JSON Web Token pour voir son en-tête, sa charge utile et sa signature — ou signez-en un nouveau avec HS256/384/512. Vérification HMAC locale. 100% dans votre navigateur.
Décodez n'importe quel JSON Web Token pour voir son en-tête, sa charge utile et sa signature — ou signez-en un nouveau avec HS256/384/512. Vérification HMAC locale. 100% dans votre navigateur.
Non. L'outil entier est en JavaScript dans cette page. Collez un token, le décodage a lieu dans votre navigateur, les octets ne quittent jamais l'onglet. Ouvrez DevTools → Réseau et observez — aucune requête n'est envoyée pendant le décodage ou la vérification. Vous pouvez donc coller en toute sécurité de vrais tokens clients ou de production.
Elle prouve que le token a été signé par quelqu'un détenant le secret (HMAC) ou la clé privée (RSA/ECDSA). Elle ne chiffre PAS la charge utile — l'en-tête et la charge utile ne sont que du JSON encodé en base64url, n'importe qui possédant le token peut les lire. La signature empêche uniquement la falsification : si vous changez un seul octet de la charge utile, la signature ne correspond plus.
Un JWT contient souvent l'identifiant utilisateur, l'e-mail, les scopes, et parfois l'équivalent de cookies de session — exactement les données que vous ne devez PAS coller dans le serveur d'un inconnu. Le décodeur d'iKit s'exécute en JavaScript déjà chargé dans l'onglet de votre navigateur. Vérifiable dans DevTools → Réseau : aucun fetch, aucun XHR, aucun beacon pendant le décodage ou la vérification.
Pour les tokens HS256/384/512, saisissez le secret de signature pour vérifier la signature localement. Pour RS256/ES256 (RSA/ECDSA), utilisez une bibliothèque côté serveur — la vérification par clé publique nécessite un fichier PEM que nous n'acceptons pas ici.
HS256 nécessite au moins 32 octets (256 bits) pour une vraie robustesse cryptographique. N'importe quoi convient pour les tests, mais en production utilisez un secret long et aléatoire.
Le moyen le plus rapide de déboguer un JWT — sans envoi, sans inscription, sans tiers entre vous et votre token.
Collez un JWT et voyez l'en-tête, la charge utile et la signature décodés côte à côte. Les claims standard (iss, sub, aud, exp, iat) sont horodatés et étiquetés.
Pour les tokens HS256/384/512, saisissez le secret pour vérifier la signature via l'API Web Crypto du navigateur. Le secret ne quitte jamais votre onglet.
Passez en mode Encoder, modifiez l'en-tête et la charge utile en JSON, choisissez l'algorithme, saisissez un secret et obtenez instantanément un token signé.
Les charges utiles JWT contiennent des identifiants utilisateur, des e-mails, parfois des scopes — ne les collez jamais dans un outil serveur. Le décodeur d'iKit s'exécute en JavaScript dans votre navigateur. Vérifiable dans DevTools → Réseau.
Les claims standard comme exp, nbf, iat sont mis en évidence avec des dates lisibles et un badge clair EXPIRÉ / valide afin de savoir d'un coup d'œil si le token est encore bon.
Construit sur l'API Web Crypto native du navigateur et le parseur JSON — mêmes algorithmes qu'OpenSSL, libjwt, jose. Le comportement correspond à toutes les bibliothèques JWT modernes.
Un JWT est composé de trois segments JSON encodés en base64url, séparés par des points — c'est tout.
Un JWT ressemble à aaa.bbb.ccc. On découpe sur les deux points littéraux, ce qui donne l'en-tête, la charge utile et la signature encodés. Si l'on n'obtient pas exactement trois parties, le token est mal formé.
L'en-tête et la charge utile sont du JSON UTF-8 encodé en base64url. Base64URL = Base64 avec -/_ à la place de +//= et sans padding. On effectue atob après avoir remis les caractères en place, puis JSON.parse sur la chaîne obtenue.
L'en-tête nous indique l'algorithme (alg : HS256, RS256, etc.) et le type. La charge utile contient les claims — les standards (iss, sub, aud, exp, iat, nbf, jti) plus les champs personnalisés. Nous affichons chacun dans une section étiquetée.
Pour HS256/384/512, on recalcule le HMAC de header.payload à l'aide du secret saisi et on le compare à la signature du troisième segment. Identique à HMAC(SHA-256, secret, signing_input) encodé en base64url. Correspondance = signature valide.
Situations réelles où vous aurez besoin d'un décodeur JWT.
Auth0, Firebase, Keycloak, AWS Cognito renvoient tous des JWT après connexion. Collez l'access_token pour voir quels claims votre application reçoit réellement — quel est l'identifiant utilisateur, quels scopes, quand expire-t-il ?
L'API rejette votre requête ? Décodez le token pour vérifier : est-il expiré (exp dans le passé) ? Le claim audience (aud) correspond-il à ce que l'API attend ? L'émetteur (iss) est-il le bon tenant ?
Stripe, GitHub Apps, Slack envoient des charges utiles de webhook signées sous forme de JWT. Après réception, collez-les en mode Décoder avec le secret partagé pour confirmer que la requête vient bien d'eux.
Besoin d'un JWT signé tout neuf pour un test d'intégration ? Passez en mode Encoder, modifiez la charge utile (identifiant utilisateur personnalisé, expiration personnalisée), choisissez HS256 + votre secret de test, obtenez un token en quelques millisecondes. Aucun aller-retour avec le backend.
Un JWT contient souvent l'identifiant utilisateur, l'e-mail, les scopes, et parfois l'équivalent de cookies de session — exactement les données que vous ne devez PAS coller dans le serveur d'un inconnu. Le décodeur d'iKit s'exécute en JavaScript déjà chargé dans l'onglet de votre navigateur. Vérifiable dans DevTools → Réseau : aucun fetch, aucun XHR, aucun beacon pendant le décodage ou la vérification.
Tutoriels détaillés et comparaisons d'outils du blog iKit.
JWT segments are base64url-encoded JSON — understand the encoding before you debug a token.
JWT signatures are HMAC-SHA hashes — the same family of cryptographic hashes used to verify file integrity.
Non. L'outil entier est en JavaScript dans cette page. Collez un token, le décodage a lieu dans votre navigateur, les octets ne quittent jamais l'onglet. Ouvrez DevTools → Réseau et observez — aucune requête n'est envoyée pendant le décodage ou la vérification. Vous pouvez donc coller en toute sécurité de vrais tokens clients ou de production.
Elle prouve que le token a été signé par quelqu'un détenant le secret (HMAC) ou la clé privée (RSA/ECDSA). Elle ne chiffre PAS la charge utile — l'en-tête et la charge utile ne sont que du JSON encodé en base64url, n'importe qui possédant le token peut les lire. La signature empêche uniquement la falsification : si vous changez un seul octet de la charge utile, la signature ne correspond plus.
Trois causes courantes : (1) mauvais secret — les secrets JWT sont sensibles à la casse et tout espace en trop casse la vérification. (2) Incompatibilité d'algorithme — l'en-tête indique HS256 mais le secret a été utilisé à l'origine avec HS512. (3) Le token a été modifié après signature — un seul octet suffit à casser la signature. Vérifiez que header.alg correspond à ce que vous attendez.
iKit ne prend actuellement en charge que la vérification HMAC (HS256/384/512). RS256 et ES256 utilisent la cryptographie à clé publique — la vérification nécessite la clé publique de l'émetteur au format PEM, ce qui demande une interface plus élaborée. Pour l'instant, le décodage fonctionne quand même (les parties en-tête/charge utile/signature s'affichent correctement), mais le bouton Vérifier vous indiquera que ce n'est pas pris en charge. La vérification RSA/ECDSA est prévue.
Même idée, valeurs par défaut différentes. Le décodeur d'iKit s'exécute entièrement dans votre navigateur (jwt.io aussi, mais le code d'iKit est consultable via view-source et notre domaine n'a aucun traceur tiers). Nous ajoutons un badge clair EXPIRÉ / valide pour le claim exp, des notes structurées sur les claims (iat / nbf / iss / sub / aud / jti sous forme de lignes lisibles), et un bouton tout-copier-décodé qui vous donne la sortie complète structurée à coller dans un rapport de bug.