Encodeur et décodeur Base64 / URL / JWT
Encodez et décodez du Base64 ou des URL, et inspectez l’en-tête et la charge utile d’un JWT dans le navigateur.
Mode d'emploi
- Collez ou saisissez votre contenu dans la zone « Texte ou JWT » : du texte à encoder, une chaîne Base64 ou encodée en pourcentage à décoder, ou un JWT à examiner.
- Cliquez sur « Encoder en Base64 » ou « Décoder le Base64 » pour passer du texte au Base64 et inversement, ou sur « Encoder l’URL » ou « Décoder l’URL » pour ajouter ou retirer l’encodage en pourcentage. Le résultat, ou un message d’erreur, s’affiche dans la zone « Sortie ».
- Pour examiner un jeton, collez-le avec ou sans le préfixe Bearer et cliquez sur « Décoder le JWT ». L’en-tête et la charge utile s’affichent en JSON indenté, et les claims iat, nbf et exp éventuellement présents dans la charge utile sont listés sous « Claims temporels du JWT », avec leurs valeurs numériques converties en UTC et dans votre heure locale.
- Cliquez sur « Copier le résultat » pour copier la sortie. Pour annuler un encodage, collez le texte encodé dans la zone « Texte ou JWT » et cliquez sur le bouton de décodage correspondant. Décoder puis réencoder ne redonne pas forcément l’original exact : un Base64 URL-safe ou sans remplissage revient avec l’alphabet standard et, si nécessaire, le remplissage =, et « Encoder l’URL » transforme en %2B un + laissé tel quel par « Décoder l’URL ».
Questions fréquentes
Le texte ou le jeton que je colle est-il envoyé quelque part ?
Non. L’encodage et le décodage s’effectuent dans votre navigateur en JavaScript, et ce que vous saisissez n’est pas envoyé à LeedyBox. Un JWT sert souvent d’identifiant de connexion et peut fonctionner pour quiconque le détient, jusqu’à son expiration ou sa révocation : traitez un jeton valide comme un mot de passe et ne le partagez pas dans des captures d’écran ou des messageries.
Pourquoi « Décoder le Base64 » indique-t-il que les données ne sont pas du texte UTF-8 valide ?
« Décoder le Base64 » affiche les octets décodés sous forme de texte UTF-8 et s’arrête avec cette erreur s’ils ne forment pas de l’UTF-8 valide, par exemple pour des images PNG ou JPEG, la plupart des PDF et des données compressées, et souvent pour du texte enregistré dans un autre encodage comme Latin-1 ou Shift_JIS. L’outil n’enregistre pas les octets décodés dans un fichier : utilisez-le pour du Base64 qui contient du texte. Une URI de données comme data:image/png;base64,... est refusée comme Base64 non valide, car les deux-points, le point-virgule et la virgule ne sont pas des caractères Base64.
Le Base64 URL-safe et l’absence de remplissage sont-ils pris en charge ?
Oui, au décodage : « Décoder le Base64 » accepte l’alphabet standard (+ et /) et l’alphabet URL-safe (- et _), avec ou sans remplissage =, et ignore les espaces et les sauts de ligne. « Encoder en Base64 » produit l’alphabet standard avec remplissage ; pour la forme URL-safe utilisée dans les JWT, remplacez + par -, / par _ et supprimez les signes = finaux. Le texte est encodé en UTF-8 tel qu’il a été saisi : une espace ou un saut de ligne en fin de texte change donc le résultat, et les sauts de ligne de la zone sont encodés en LF.
Faut-il encoder une URL entière avec « Encoder l’URL » ?
En général, non. « Encoder l’URL » fonctionne comme encodeURIComponent en JavaScript : il encode en pourcentage tous les caractères sauf A–Z, a–z, 0–9 et - _ . ! ~ * ' ( ), si bien que les caractères / ? & = : et # qui structurent une URL sont aussi encodés. Utilisez-le pour une seule partie, comme la valeur d’un paramètre de requête. Les espaces deviennent %20 et les caractères non ASCII sont encodés selon leurs octets UTF-8 : é devient ainsi %C3%A9.
Pourquoi les signes plus ne deviennent-ils pas des espaces, et quand « Décoder l’URL » signale-t-il une erreur ?
« Décoder l’URL » fonctionne comme la fonction decodeURIComponent de JavaScript : il décode les séquences d’échappement %XX et laisse les + inchangés, car dans la syntaxe générale des URL (RFC 3986), + ne représente pas une espace. Les données de formulaires HTML (application/x-www-form-urlencoded), qu’utilisent de nombreuses chaînes de requête, encodent les espaces par des + : remplacez donc chaque + par une espace avant de décoder ces données. Dans ce format, un vrai signe plus s’écrit %2B et il est quand même décodé correctement. L’erreur apparaît lorsqu’un % n’est pas suivi de deux chiffres hexadécimaux, comme dans 50% off, ou lorsque les octets échappés ne forment pas de l’UTF-8 valide, comme dans %E2%82.
Quels jetons « Décoder le JWT » peut-il lire ?
Les jetons au format compact en trois parties header.payload.signature utilisé par les JWT signés (JWS), y compris les jetons non signés dont la partie signature est vide. La partie signature n’est pas vérifiée : un jeton décodé ne prouve donc pas qu’il est authentique. Les jetons chiffrés (JWE) comportent cinq parties et leur charge utile est illisible sans la clé : ils provoquent une erreur de format. Un en-tête ou une charge utile qui ne donne pas du JSON une fois décodé du Base64, ou une charge utile qui est une simple valeur, comme une chaîne ou un nombre, au lieu d’un objet JSON, provoque le message « Erreur d’analyse du JWT ». Les entiers supérieurs à 9 007 199 254 740 991 dans l’en-tête ou la charge utile peuvent être arrondis lorsque le navigateur analyse le JSON : les identifiants numériques longs peuvent donc s’afficher avec des derniers chiffres différents.
Comment les dates exp, nbf et iat sont-elles affichées, et quand un jeton est-il marqué comme expiré ?
Les valeurs sont lues comme un temps Unix en secondes, comme le définit la norme JWT (RFC 7519), et affichées en UTC et dans votre heure locale. « EXPIRÉ » et « Pas encore valide » comparent exp et nbf avec l’horloge de votre appareil au moment où vous cliquez sur « Décoder le JWT », sans tolérance pour un éventuel décalage d’horloge : si l’horloge est fausse, l’état affiché l’est aussi. Les serveurs peuvent accorder une petite marge, souvent de quelques minutes au plus : à l’approche de l’heure exp ou nbf, un serveur peut donc décider autrement que l’état affiché ici. Une date écrite sous forme de chaîne, comme "1700000000", est signalée comme n’étant pas un horodatage Unix numérique valide.