Encodez ou décodez Base64, Base64URL, l'encodage URL en pourcentage, les entités HTML et l'hexadécimal pendant la saisie, avec prise en charge complète de l'UTF-8.
Rien de ce que vous saisissez n'est conservé : c'est converti et renvoyé dans la même requête.
Un jeton dans un log, une chaîne de requête dans une redirection, un e-mail plein de & : le texte encodé est partout au travail. Collez-le ici, choisissez le format et voyez le résultat encodé ou décodé au fil de la saisie.
Un JSON Web Token est formé de trois parties Base64URL séparées par des points : en-tête, charge utile et signature. Collez la partie centrale, choisissez Base64URL et décodez : vous voyez les claims JSON, comme l'identifiant utilisateur et l'expiration exp (un timestamp Unix lisible avec le Convertisseur de timestamp Unix). Décoder n'est pas vérifier : n'importe qui peut lire la charge utile d'un JWT, et seule la vérification de la signature côté serveur prouve qu'elle n'a pas été modifiée.
Un Base64 dont le padding a été retiré, ce que certains systèmes font pour gagner de la place, échoue dans les décodeurs stricts ; cet outil ajoute les signes = manquants et vous le signale. Pour beaucoup de serveurs, un + dans une chaîne de requête signifie une espace, donc une valeur Base64 collée telle quelle dans un lien arrive corrompue ; encodez-la comme composant d'URL ou utilisez Base64URL. Un texte encodé deux fois apparaît sous la forme %2520 ou & et doit être décodé deux fois.
Le décodage Base64 ignore les espaces et les retours à la ligne : une valeur coupée sur plusieurs lignes, comme dans un e-mail, se décode telle quelle. Base64URL accepte aussi + et /, mais le Base64 standard refuse - et _ : une partie de JWT demande donc l'option Base64URL. Le décodage hexadécimal ignore espaces, deux-points, virgules, tirets et préfixes 0x : 48:65:6c:6c:6f et 0x48 0x65 fonctionnent tous deux. Le décodage URL transforme + en espace : un vrai signe plus doit arriver sous la forme %2B. L'encodage HTML échappe les cinq caractères & < > " et ' ; le décodage HTML comprend toutes les entités nommées de HTML5, comme et …, ainsi que les entités numériques comme ₹ pour le symbole de la roupie.
L'encodage URL de cet outil encode une seule valeur, par exemple un paramètre de requête, donc chaque caractère réservé est échappé : https://example.com/a b?x=1&y=2 devient https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2. N'encodez que la valeur que vous insérez dans un lien, jamais le lien entier. Le texte hors ASCII est encodé sous forme de ses octets UTF-8 : café ₹ devient caf%C3%A9%20%E2%82%B9, et l'hexadécimal montre les mêmes octets, é en c3 a9 et ₹ en e2 82 b9. Le Base64 de user:pass est dXNlcjpwYXNz, la valeur que transporte un en-tête HTTP Basic Authorization (RFC 7617) : quiconque voit cet en-tête peut donc lire le mot de passe.
Les octets étaient en UTF-8 mais ont été lus quelque part en Latin-1 ou Windows-1252 avant d'être encodés. Le décodage ici montre les octets tels qu'ils sont ; la correction relève du système qui les a produits.
Collez jusqu'à 200 000 caractères de texte. Pour les fichiers binaires comme les images, les octets décodés s'affichent en hexadécimal au lieu de devenir un téléchargement.
Non. Le Base64 change seulement la façon d'écrire les octets pour qu'ils passent dans des systèmes qui attendent du texte brut. N'importe qui peut le décoder ; ne l'utilisez jamais pour cacher un mot de passe ou un secret.
Base64URL remplace "+" et "/" par "-" et "_" et supprime en général le padding "=", ce qui rend le résultat sûr dans les URL et les noms de fichiers. Les JSON Web Tokens l'utilisent.
Non. Il est converti et renvoyé dans la même requête, et n'est jamais écrit dans une base de données ni dans un journal.
Cet outil échappe aussi ! ' ( ) et *, que encodeURIComponent laisse tels quels : it's (50%) off! devient donc it%27s%20%2850%25%29%20off%21. Les deux formes se décodent en le même texte, et échapper ces caractères est toujours sans risque dans une valeur de requête. Une espace devient %20, pas + ; la forme + vient de l'encodage des formulaires HTML, et le décodeur ici lit les deux.
Sous Linux ou Mac, echo -n 'Hello, World' | base64 donne SGVsbG8sIFdvcmxk, et echo 'SGVsbG8sIFdvcmxk' | base64 --decode le retransforme en texte. Sans -n, echo ajoute un saut de ligne qui est encodé lui aussi, ce qui donne SGVsbG8sIFdvcmxkCg== : la raison la plus fréquente pour laquelle deux outils ne sont pas d'accord. Dans PowerShell, [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) encode et [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) décode. Cette page encode exactement les caractères que vous collez, en UTF-8, sans ajouter de saut de ligne.
Collez seulement la partie après la virgule : dans data:image/png;base64,iVBORw0KGgo..., c'est iVBORw0KGgo..., car le préfixe data:image/png;base64, n'est pas du Base64 et la chaîne entière est refusée. Choisissez Base64 puis Decode. Les octets qui ne sont pas du texte s'affichent en hexadécimal au lieu d'être dessinés en image, ce qui suffit pour savoir de quel fichier il s'agit : un PNG commence par 89 50 4e 47, un JPEG par ff d8 ff, et un fichier .docx, .xlsx ou autre fichier ZIP complet par 50 4b 03 04. Pour voir l'image elle-même, collez la data URI complète dans la barre d'adresse du navigateur. L'entrée est limitée à 200 000 caractères, soit environ 150 000 octets de fichier.
Le Base64 écrit chaque groupe de 3 octets en 4 caractères et complète le dernier groupe avec des = jusqu'à un multiple de 4 (RFC 4648) : la sortie fait 4/3 des octets d'entrée, arrondi au-dessus. Hello, World fait 12 octets et devient les 16 caractères SGVsbG8sIFdvcmxk. On compte des octets UTF-8, pas des lettres : café fait 4 caractères mais 5 octets et donne Y2Fmw6k=, et ₹100 fait 6 octets et donne 4oK5MTAw. Les pièces jointes d'e-mail grossissent un peu plus, car MIME coupe le Base64 en lignes de 76 caractères au plus (RFC 2045) ; cette page ignore ces retours à la ligne au décodage. Le Base64URL sans remplissage n'économise que les signes =.