Encodeur JWT

Créez et signez des JSON Web Tokens avec HS256, HS384, HS512

En-tête

Fonctionne localement · Sûr pour coller des secrets

Charge utile

Fonctionne localement · Sûr pour coller des secrets

Clé secrète

Fonctionne localement · Sûr pour coller des secrets

JWT encodé

Output will appear here…

Votre clé secrète ne quitte jamais votre navigateur. Toute la signature se fait côté client.

Essayez aussi :Décodeur JWT

Qu'est-ce que l'encodage JWT ?

L'encodage JWT est le processus de création d'un JSON Web Token — une chaîne compacte et sécurisée pour les URL qui porte un ensemble de revendications signées avec une clé cryptographique. Le résultat est un token en trois parties (en-tête.charge.signature) défini par RFC 7519 que les serveurs peuvent vérifier sans maintenir l'état de la session. L'encodage JWT en ligne te permet de créer et de signer des tokens directement dans ton navigateur pour les tests et le développement.

L'en-tête déclare l'algorithme de signature (par exemple HS256) et le type de token. La charge utile contient des revendications — des paires clé-valeur comme le sujet (sub), le temps d'expiration (exp) et toute donnée personnalisée dont ton application a besoin. Les deux parties sont sérialisées en JSON, puis encodées en base64url. La signature est calculée sur l'en-tête et la charge codifiés à l'aide d'une clé secrète, liant les trois segments ensemble.

Contrairement aux cookies de session, les JWT sont autonomes : le vérificateur n'a pas besoin d'interroger une base de données ou d'appeler un service externe. Cela rend l'authentification basée sur JWT populaire dans les API REST, les microservices et les applications monopage où l'autorisation sans état réduit la latence et simplifie la scalabilité horizontale.

Pourquoi utiliser un encodeur JWT ?

La génération manuelle de JWT nécessite l'encodage base64url, la sérialisation JSON et le calcul HMAC. Cet outil gère les trois étapes instantanément pour que tu puisses te concentrer sur l'obtention des bonnes revendications.

Génération instantanée de tokens
Modifie l'en-tête, la charge utile et la clé secrète — le JWT signé se met à jour en temps réel. Pas d'étape de build, pas d'installation de bibliothèque, pas de code standard.
🔒
Plusieurs algorithmes HMAC
Bascule entre HS256, HS384 et HS512 en un clic. L'en-tête se met à jour automatiquement et la signature est recalculée immédiatement.
🛡️
Traitement respectueux de la vie privée
Toute la signature se fait dans ton navigateur à l'aide de l'API Web Crypto. Ta clé secrète et tes données de charge utile ne quittent jamais ta machine — pas de serveur, pas de journaux, pas de risque.
📋
Aides à revendication en un clic
Ajoute les timestamps iat, exp+1h ou exp+24h avec un seul bouton. Pas besoin de calculer manuellement les timestamps Unix ou de chercher l'heure d'époque actuelle.

Cas d'usage de l'encodeur JWT

Tests d'authentification frontend
Génère des tokens avec des revendications et des délais d'expiration spécifiques pour tester les flux de connexion, la logique d'actualisation des tokens et les protections de routes sans exécuter un serveur d'authentification backend.
Développement d'API backend
Crée des tokens de test avec des revendications sub, aud et scope personnalisées pour tester l'intergiciel d'autorisation, le contrôle d'accès basé sur les rôles et les vérifications de permissions lors du développement local.
Pipelines DevOps et CI/CD
Génère des tokens de courte durée pour les scripts de déploiement, les tests d'intégration ou la communication entre services où un flux OAuth complet ajouterait une complexité inutile.
Tests QA et manuels
Construis des tokens avec des revendications de cas limites — tokens expirés, champs manquants, audiences incorrectes — pour vérifier que ton API retourne les bonnes réponses HTTP 401 ou 403.
Audit de sécurité
Crée des tokens signés avec différents algorithmes et longueurs de clés pour valider que ta logique de vérification rejette correctement les signatures faibles ou incompatibles.
Apprentissage et prototypage
Les étudiants et les nouveaux développeurs JWT peuvent expérimenter avec les champs d'en-tête, les structures de revendications et les algorithmes de signature pour comprendre comment chaque partie du token fonctionne.

HS256 vs HS384 vs HS512 : Comparaison des algorithmes HMAC

Les trois algorithmes utilisent HMAC (Hash-based Message Authentication Code) avec un secret partagé. La différence réside dans la fonction de hachage sous-jacente, qui affecte la longueur de la signature et la marge de sécurité. Pour la plupart des applications, HS256 offre une sécurité suffisante. Choisis HS384 ou HS512 lorsque les exigences de conformité (par exemple FIPS-140) exigent un hachage plus fort ou lorsque tes tokens portent des décisions d'autorisation de haute valeur.

AlgorithmeHashSignatureVitesseUtilisation typique
HS256SHA-25632 BFastestGeneral purpose, default for most libraries
HS384SHA-38448 BFastHigher security margin, FIPS-140 compliant
HS512SHA-51264 BFastMaximum HMAC security, large payloads

Référence des revendications JWT standard

RFC 7519 définit sept revendications enregistrées. Aucune n'est obligatoire, mais les utiliser correctement améliore l'interopérabilité et la sécurité. La revendication exp est particulièrement importante — les tokens sans expiration sont valides indéfiniment si le secret n'est pas rotaté.

RevendicationNomDescriptionExemple
issIssuerWho issued the token"auth.example.com"
subSubjectWho the token represents"user-123"
audAudienceIntended recipient service"api.example.com"
expExpirationUnix timestamp — token invalid after this time1717203600
nbfNot BeforeUnix timestamp — token invalid before this time1717200000
iatIssued AtUnix timestamp when the token was created1717200000
jtiJWT IDUnique token identifier for revocation tracking"a1b2c3d4"

Encodage JWT dans le code

Ces exemples montrent comment créer et signer les JWT par programmation. Chaque extrait produit un token valide signé avec HS256. Pour les systèmes de production, définissez toujours la revendication exp et utilisez un secret cryptographiquement aléatoire d'au moins 256 bits.

JavaScript (Web Crypto API)
async function signJWT(payload, secret, alg = 'HS256') {
  const header = { alg, typ: 'JWT' }
  const enc = new TextEncoder()

  // Base64url encode header and payload
  const b64url = (obj) =>
    btoa(JSON.stringify(obj)).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  const h = b64url(header)
  const p = b64url(payload)

  // Sign with HMAC-SHA256
  const key = await crypto.subtle.importKey(
    'raw', enc.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
  )
  const sig = await crypto.subtle.sign('HMAC', key, enc.encode(`${h}.${p}`))
  const s = btoa(String.fromCharCode(...new Uint8Array(sig)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  return `${h}.${p}.${s}`
}

// Usage
const token = await signJWT(
  { sub: 'user-123', name: 'Alice', iat: Math.floor(Date.now() / 1000) },
  'your-256-bit-secret'
)
// → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."
Python (PyJWT)
import jwt
import time

payload = {
    "sub": "user-123",
    "name": "Alice",
    "iat": int(time.time()),
    "exp": int(time.time()) + 3600,  # expires in 1 hour
}

# Sign with HS256 (default)
token = jwt.encode(payload, "your-256-bit-secret", algorithm="HS256")
# → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."

# Verify and decode
decoded = jwt.decode(token, "your-256-bit-secret", algorithms=["HS256"])
# → {"sub": "user-123", "name": "Alice", "iat": 1717200000, "exp": 1717203600}
Node.js (jsonwebtoken)
const jwt = require('jsonwebtoken')

const payload = {
  sub: 'user-123',
  name: 'Alice',
  role: 'admin',
}

// Sign — iat is added automatically
const token = jwt.sign(payload, 'your-256-bit-secret', {
  algorithm: 'HS256',
  expiresIn: '1h',    // sets exp claim
  issuer: 'auth.example.com',  // sets iss claim
})

// Verify
const decoded = jwt.verify(token, 'your-256-bit-secret')
// → { sub: 'user-123', name: 'Alice', role: 'admin', iat: ..., exp: ... }
Go (golang-jwt)
package main

import (
    "fmt"
    "time"
    "github.com/golang-jwt/jwt/v5"
)

func main() {
    claims := jwt.MapClaims{
        "sub":  "user-123",
        "name": "Alice",
        "iat":  time.Now().Unix(),
        "exp":  time.Now().Add(time.Hour).Unix(),
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    signed, _ := token.SignedString([]byte("your-256-bit-secret"))
    fmt.Println(signed)
    // → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOi...
}

Questions fréquemment posées

Quelle est la différence entre l'encodage JWT et le décodage JWT ?
L'encodage JWT crée un token signé à partir d'un en-tête, d'une charge utile et d'une clé secrète. Le décodage JWT inverse le processus — il relit l'en-tête et la charge utile encodés en base64url en JSON. Le décodage ne nécessite pas le secret ; l'encodage le nécessite toujours car la signature doit être calculée.
Quelle doit être la longueur de ma clé secrète JWT ?
Pour HS256, utilisez un secret d'au moins 256 bits (32 octets). Pour HS384, au moins 384 bits (48 octets). Pour HS512, au moins 512 bits (64 octets). Les secrets plus courts sont techniquement acceptés par la plupart des bibliothèques mais réduisent la sécurité effective de la signature HMAC. Générez des secrets avec un générateur aléatoire cryptographiquement sécurisé, pas une phrase choisie par l'homme.
Est-il sûr d'utiliser cet outil avec des vrais secrets ?
Cet outil traite tout dans ton navigateur en utilisant l'API Web Crypto — aucune donnée n'est envoyée à un serveur. Cela dit, évite de coller des secrets de production dans n'importe quel outil web comme pratique générale de sécurité. Pour la gestion des clés en production, utilisez des variables d'environnement ou un gestionnaire de secrets comme HashiCorp Vault ou AWS Secrets Manager.
Dois-je utiliser HS256 ou RS256 pour mon application ?
Utilisez HS256 lorsque le même service crée et vérifie les tokens — c'est plus rapide et plus simple. Utilisez RS256 (asymétrique) lorsque les services tiers doivent vérifier vos tokens sans pouvoir les créer. RS256 est courant dans les fournisseurs OAuth 2.0, OpenID Connect et les architectures SaaS multi-locataires.
Pourquoi mon JWT expire-t-il immédiatement après sa création ?
La revendication exp utilise les timestamps Unix en secondes, pas en millisecondes. Si vous définissez exp sur Date.now() (qui retourne des millisecondes), le token semblera expirer des milliers d'années à l'avenir — ou si vous utilisez accidentellement une valeur en millisecondes où les secondes sont attendues, les bibliothèques peuvent l'interpréter comme déjà expiré. Utilisez toujours Math.floor(Date.now() / 1000) en JavaScript ou int(time.time()) en Python.
Puis-je mettre des données sensibles dans la charge utile JWT ?
Vous pouvez, mais vous ne devriez pas. La charge utile JWT est codée en base64url, pas chiffrée — n'importe qui avec le token peut lire les revendications. Ne stockez pas les mots de passe, les numéros de carte de crédit ou les données personnelles dans la charge utile. Si vous devez inclure des informations sensibles, utilisez JWE (JSON Web Encryption) comme défini dans RFC 7516, qui chiffre toute la charge utile.
Que se passe-t-il si je modifie la charge utile après la signature ?
La signature devient invalide. La signature HMAC est calculée sur les octets exacts de l'en-tête et de la charge utile encodés. N'importe quel changement — même l'ajout d'un espace ou la modification d'un seul caractère — produit une signature complètement différente. Un vérificateur correctement implémenté rejettera le token avec une erreur de signature non valide.