Encodeur JWT (Générer et Signer)

Générez un JWT (JSON Web Token) signé par HMAC (HS256, HS384 ou HS512) à partir du JSON de l'en-tête et de la charge utile, directement dans votre navigateur. Rien, pas même la clé secrète, n'est envoyé à un serveur.

Dernière mise à jour : 2026-09-20

Algorithmes de signature HMAC pris en charge

Algorithme	Fonction de hachage	Longueur de signature	Description
HS256	SHA-256	256 bits (32 octets)	La signature HMAC par défaut la plus utilisée. C'est le standard dans de nombreuses implémentations, notamment les jetons d'ID OAuth 2.0 et OpenID Connect.
HS384	SHA-384	384 bits (48 octets)	Une option intermédiaire lorsqu'une signature plus longue que HS256 est souhaitée pour une marge de sécurité supplémentaire.
HS512	SHA-512	512 bits (64 octets)	Possède la plus grande longueur de signature et est généralement associée à une clé secrète aléatoire suffisamment longue.

Créer et signer un JWT

Cet outil assemble sur-le-champ un JWT à partir du JSON de l'en-tête et de la charge utile, en le signant par HMAC selon HS256, HS384 ou HS512. Tout ce que vous saisissez, la clé secrète comprise, est traité dans le seul navigateur et n'est jamais transmis à un serveur.

**Ce que l'on comprend le plus souvent de travers ici, c'est que la signature sert à détecter une altération et n'est pas un chiffrement.** L'en-tête et la charge utile d'un JWT sont simplement encodés en Base64URL, si bien que **quiconque détient le jeton peut en lire le contenu sans plus de façon.** Voilà pourquoi mots de passe et données personnelles n'ont rien à faire dans une charge utile. L'autre point tient à la nature de la clé : la famille HS repose sur le fait que **celui qui signe et celui qui vérifie partagent le même secret.** Si la vérification doit être confiée à un tiers, vous voudrez un procédé à clé publique tel que RS256 ou ES256, qui vous épargne de livrer le secret.

Comment en créer un

Saisissez le JSON de l'en-tête Il prend la forme `{"alg":"HS256","typ":"JWT"}`. Tenez-le en accord avec l'algorithme retenu.
Saisissez le JSON de la charge utile Écrivez-y les revendications nécessaires, telles que `sub`, `iat` et `exp`. **Laissez dehors tout ce qui doit rester secret.**
Choisissez l'algorithme de signature HS256, HS384 et HS512 sont proposés ; le nombre donne la longueur en bits de l'empreinte.
Fournissez le secret et recueillez le jeton Il en sort une chaîne de trois parties réunies par des points.

Astuces pour en tirer le meilleur parti

Le JWT est entièrement signé par la Web Crypto API de votre navigateur : l'en-tête, la charge utile et la clé secrète ne sont jamais envoyés au serveur de toolbase.cc.
Changer d'algorithme de signature (HS256/HS384/HS512) met automatiquement à jour le champ alg de l'en-tête JSON. Modifiez l'en-tête directement si vous souhaitez ajouter d'autres revendications comme kid.
Cet outil ne prend en charge que les algorithmes HMAC (clé symétrique). Si vous avez besoin d'un algorithme à clé publique comme RS256 ou ES256, utilisez une bibliothèque côté serveur, par exemple un module JWT pour Node.js.
Après avoir modifié l'en-tête ou la charge utile, pensez à cliquer à nouveau sur « Générer le JWT » — sinon le jeton affiché reste signé avec la saisie précédente.
Pour vérifier le contenu d'un JWT tout juste généré, collez-le dans l'outil complémentaire Décodeur JWT afin de contrôler l'en-tête et la charge utile.

Dans quels cas s'en servir

Pour éprouver le comportement d'une API

**Pouvoir frapper un jeton portant les revendications que l'on veut accélère le parcours des branches d'une règle d'autorisation.**

Pour vérifier le traitement de l'expiration

Créez un jeton dont l'`exp` est dans le passé et confirmez qu'un jeton expiré est bien écarté.

Pour préparer des jetons de test

Vous pouvez produire un jeton au contenu fixe qui servira de matière dans un test automatisé.

Pour apprendre la structure d'un JWT

Générer à plusieurs reprises en faisant varier l'entrée laisse voir à quel endroit du jeton chaque pièce aboutit.

Vocabulaire du JWT

En-tête: La première partie, qui énonce l'algorithme et le type. Elle porte `alg` et `typ`.
Charge utile: La deuxième partie, qui abrite les revendications. **Elle n'est qu'encodée en Base64URL et n'est aucunement chiffrée.**
Signature: La troisième partie, calculée depuis l'en-tête et la charge utile à l'aide d'une clé. **Elle sert à détecter une altération et ne fait rien pour dissimuler le contenu.**
Revendication: Chaque entrée au sein de la charge utile. Parmi les standard figurent `sub` pour le sujet, `iat` pour l'heure d'émission et `exp` pour l'expiration.
HMAC: Un procédé d'authentification de message à clé partagée. **Celui qui signe comme celui qui vérifie doivent détenir le même secret.**
Base64URL: Du Base64 dont les symboles sont remplacés pour voyager dans une URL : `+` et `/` deviennent `-` et `_`, et le remplissage final est supprimé.

Questions fréquentes

Non, ce n'est pas recommandé. Bien que la signature elle-même se déroule de manière sûre dans le navigateur, saisir une clé secrète de production dans un outil de navigateur n'est pas une bonne pratique du point de vue de la sécurité. Cet outil est destiné à vérifier le comportement d'une API pendant le développement ou à des fins d'apprentissage.

HS256 est un algorithme à clé symétrique où l'expéditeur et le destinataire partagent la même clé secrète, tandis que RS256 est un algorithme à clé publique (asymétrique) où une clé privée signe et une clé publique vérifie. Cet outil ne prend en charge que la famille HMAC — HS256, HS384 et HS512 — et ne prend pas en charge les algorithmes à clé publique comme RS256 ou ES256.

Oui, vous pouvez modifier directement l'en-tête JSON. Cependant, si l'algorithme sélectionné (celui réellement utilisé pour calculer la signature) ne correspond pas à la valeur du champ alg, une autre implémentation vérifiant le jeton pourrait le rejeter avec une erreur — veillez donc à ce que les deux correspondent toujours.

Vous pouvez coller la chaîne JWT générée dans l'outil complémentaire « Décodeur JWT » pour vérifier instantanément le contenu de l'en-tête et de la charge utile. La validité réelle de la signature ne peut toutefois être confirmée de manière définitive que par la logique de vérification côté serveur qui détient la même clé secrète.

Anecdote — Pourquoi la signature d'un JWT peut se faire entièrement dans le navigateur

Les algorithmes de signature JWT se répartissent en deux grandes familles : les algorithmes à « clé symétrique » (HMAC, c'est-à-dire HS256/HS384/HS512), où l'expéditeur et le destinataire partagent la même clé secrète, et les algorithmes à « clé publique » (comme RS256 et ES256), où une clé privée signe et une clé publique vérifie. Les premiers pouvant être calculés entièrement grâce à crypto.subtle.sign() de la Web Crypto API (SubtleCrypto) normalisée par le W3C, sans aucune bibliothèque externe, cet outil se limite volontairement aux algorithmes HMAC.

La sécurité d'une signature HMAC dépend entièrement de la difficulté à deviner la clé secrète, et non du contenu de l'en-tête ou de la charge utile. Le RFC 7518 (JSON Web Algorithms) recommande une longueur de clé d'au moins 256 bits (32 octets) pour HS256 ; utiliser un mot court ou une chaîne de dictionnaire comme clé secrète expose à un risque de falsification de la signature par force brute. En production réelle, il convient d'utiliser une chaîne aléatoire suffisamment longue générée par un générateur de nombres aléatoires.

Cet outil est un utilitaire pour développeurs destiné à vérifier le comportement d'une API pendant le développement ou à tester la logique de vérification de signature des webhooks. La clé secrète que vous saisissez n'est traitée que dans la mémoire de votre navigateur et n'est jamais transmise à l'extérieur, mais le risque qu'un appareil partagé ou une extension de navigateur collecte le presse-papiers ou les saisies n'est pas nul. Nous recommandons fortement de ne jamais saisir dans un tel outil une clé réellement utilisée en production, même juste pour vérifier son fonctionnement.

Voir toutes les anecdotes