§

Collez votre JWT

L'analyse et la vérification de signature s'exécutent toutes deux localement. Aucune information sur le jeton n'est envoyée à un serveur.
§

En-tête

json
§

Charge utile

json
§

Vérifier la signature

Entrez un secret pour vérifier la signature.

Les architectes IAM en France inspectent des JWT au quotidien : id_token émis par France Connect, jetons d'accès AgentConnect destinés aux agents de la fonction publique, tokens FAPI échangés avec les ASPSP du STET pour l'Open Banking conforme à la DSP2, et JWS attachés aux factures Chorus Pro signées via parapheur électronique RGS**. Les éditeurs SaaS adossés à WorkOS ou à Auth0 hébergent fréquemment leur tenant chez OVHcloud, ce qui rend le décodage local indispensable lors des incidents. Ce décodeur extrait l'en-tête, le payload et la signature directement dans le navigateur, sans envoi du jeton — précieux lorsqu'un access_token contient un sub utilisateur, un scope sensible ou une revendication acr_values exigée par l'ANSSI pour les services à fort enjeu.

// Outils Connexes

./base64-decoder
Décodeur Base64
Inspectez les segments d'en-tête et de charge utile encodés en base64url en dehors de l'enveloppe JWT.
→
./url-decoder
Décodeur URL
Extrayez les JWT des chaînes de requête encodées en pourcentage et des URL de redirection.
→
./json-formatter
Formatteur JSON
Affichez joliment et validez la charge utile décodée comme du JSON autonome.
→
./
Tous les outils
Découvrez l'ensemble des outils en ligne Ultim8Soft.
→

Qu’est-ce qu’un JSON Web Token ?

Un JSON Web Token (JWT) est une enveloppe compacte et sûre pour les URL contenant une petite charge utile de revendications. C'est le format de référence pour les sessions web sans état, les jetons d'identification OAuth/OIDC, l'authentification d'API de machine à machine et les liens magiques signés. Un JWT se compose toujours de trois segments base64url joints par des points : header.payload.signature. L'en-tête et la charge utile sont du JSON ; la signature est un MAC binaire ou une signature numérique calculée sur les deux premiers segments.

Comment fonctionnent les JWT ?

Lorsque cet outil décode un jeton, il suit les mêmes trois étapes que toute bibliothèque JWT :

  1. Découper le jeton sur les points en exactement trois segments non vides. Toute autre forme est mal formée.
  2. Décoder en base64url les segments 0 et 1, puis appliquer JSON.parse à chacun. L'en-tête porte l'algorithme (alg) et le type de jeton (typ). La charge utile porte les revendications (sub, exp, iat, clés personnalisées).
  3. Si un secret est fourni, recalculer le MAC sur <segment0>.<segment1> en utilisant l'algorithme indiqué dans l'en-tête. Comparer les octets au troisième segment.
  4. Afficher le résultat de la vérification à côté des revendications décodées, avec un indicateur d'expiration lisible par l'humain calculé à partir de la revendication exp.

Pourquoi décoder les JWT dans le navigateur ?

Coller un JWT réel et utilisé dans un débogueur distant divulgue le justificatif aux journaux de ce service, à sa pile d'observabilité et à tout partenaire auquel ce service envoie des données. Même si le site tiers affirme ne pas journaliser les jetons, vous n'avez aucun moyen de le vérifier. Cet outil a été conçu pour que vous n'ayez jamais à faire ce compromis :

  • Zéro réseau : le runtime n'effectue aucun appel fetch, XMLHttpRequest ni sendBeacon. Ouvrez les DevTools pendant que vous décodez et vérifiez — le panneau Réseau reste silencieux.
  • Web Crypto natif : la vérification HMAC utilise crypto.subtle.importKey et crypto.subtle.sign, les mêmes primitives que votre runtime appellerait.
  • Déploiement statique : chaque page est un unique fichier HTML statique sans point de terminaison serveur à compromettre. Il n'y a aucun jeton à fuiter parce qu'il n'y a aucun serveur pour le fuiter.

Qu’est-ce que cet outil vérifie, et qu’est-ce qu’il ne vérifie pas ?

La version 1 de cet outil vérifie uniquement les signatures de la famille HMAC-SHA. Concrètement :

  • Pris en charge : HS256, HS384, HS512. Fournissez le secret partagé et l'outil recalculera et comparera le MAC.
  • Pas encore pris en charge : RS256/384/512 (RSA), ES256/384/512 (ECDSA), EdDSA et PS256/384/512 (RSA-PSS). Ceux-ci nécessitent une clé publique au format PEM ou JWK et sont délibérément reportés à une version ultérieure.
  • Refusé : alg: "none". L'outil décode le jeton mais le signale explicitement comme non sécurisé — aucune validation de signature n'a lieu, et tout système en production qui accepte un tel jeton présente une vulnérabilité grave.

À quoi ressemble un exemple de décodage de JWT ?

Collez le jeton d'exemple canonique de la RFC 7519 dans le champ de saisie ci-dessus :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

L'en-tête se décode en {"alg":"HS256","typ":"JWT"} et la charge utile en {"sub":"1234567890","name":"John Doe","iat":1516239022}. Saisissez your-256-bit-secret dans le panneau de vérification et le contrôle de signature retourne valide. Modifiez un seul caractère du secret et il retourne invalide. Rien de tout cela ne quitte votre navigateur.

Voici le décodeur JWT dont nous aurions souhaité l'existence quand nous avons dû déboguer un jeton en production : respectueux de la vie privée, rapide et bâti sur les mêmes primitives que celles utilisées par le runtime.