Base64 transforme des octets quelconques en une chaîne de 64 caractères sûrs, afin que des données jamais conçues comme du texte puissent traverser des canaux qui n'acceptent que du texte. Conçu pour les pièces jointes des e-mails dans les années 1990, il est toujours partout : URI de données, JWT, en-têtes d'authentification HTTP Basic, charges utiles JSON transportant des blobs binaires.
Ce que fait réellement l'encodage
L'encodeur lit l'entrée trois octets à la fois. Trois octets font 24 bits, qu'il redécoupe en quatre groupes de six bits. Six bits contiennent 64 valeurs, et chacune correspond à un caractère de l'alphabet A–Z, a–z, 0–9, plus "+" et "/". Toute l'astuce est là.
Quand la longueur de l'entrée n'est pas un multiple de trois, le dernier groupe est incomplet et l'encodeur complète la sortie avec un ou deux caractères "=", pour que le résultat soit toujours divisible par quatre. Voilà pourquoi certaines chaînes se terminent par des signes égal et d'autres non : cela indique la longueur d'origine modulo 3, rien de plus.
Les 33 % que vous payez
Quatre caractères en sortie pour trois octets en entrée signifie que la sortie Base64 est environ 33 % plus volumineuse que l'entrée. Une image de 900 Ko devient à peu près 1,2 Mo de texte. Cela pèse surtout là où l'on recourt à Base64 le plus volontiers : intégrer des images en URI de données dans le CSS ou le HTML.
L'intégration économise une requête HTTP, ce qui valait beaucoup en HTTP/1.1 et bien moins en HTTP/2 et HTTP/3, où les requêtes sont multiplexées. Le coût, lui, est réel : une image intégrée ne peut pas être mise en cache séparément du document, donc chaque modification de la page la retélécharge, et chaque visite la retélécharge avec le HTML. Règle empirique : l'intégration se défend pour des ressources minuscules — une icône de quelques centaines d'octets — et c'est une erreur pour des photographies.
Base64 n'est pas du chiffrement
C'est de loin le malentendu le plus répandu, et il provoque de vrais incidents. Base64 n'a pas de clé. Quiconque détient la chaîne la décode en une étape, y compris dans le navigateur où vous lisez ceci. Encoder un mot de passe, un jeton d'API ou la fiche d'un client en Base64 ne protège rien : cela rend seulement la valeur illisible pour un humain qui parcourt un journal, ce qui n'est pas une propriété de sécurité.
Un JWT rend la chose concrète. Son en-tête et sa charge utile sont en Base64url, non chiffrés : collez-en un dans un décodeur et vous lirez chaque claim qu'il contient. La signature empêche de *modifier* le jeton, pas de le *lire*. Ne mettez jamais dans la charge utile d'un JWT quelque chose que le porteur du jeton ne devrait pas voir.
La variante compatible URL
Le Base64 standard utilise "+" et "/", et dans une URL ces deux caractères signifient autre chose : "+" peut être lu comme une espace dans une chaîne de requête, et "/" est un séparateur de chemin. La variante base64url définie dans la RFC 4648 §5 les remplace par "-" et "_", et supprime généralement le remplissage. Si un jeton que vous décodez contient "-" ou "_" et aucun "=", vous regardez presque certainement du base64url — ce qu'utilisent les JWT.
Questions fréquentes
Mes données sont-elles envoyées à un serveur ?
Non. Cet outil porte la mention « client » : l'encodage s'exécute dans votre onglet avec son propre moteur JavaScript, et ce que vous saisissez ne quitte jamais la machine. Fermez l'onglet et il ne reste rien. Cela dit, si les données sont vraiment sensibles, utilisez un outil contrôlé par votre organisation plutôt qu'une page web gratuite quelconque — celle-ci comprise.
Pourquoi mon texte décodé affiche-t-il des caractères étranges ?
Presque toujours une incohérence d'encodage de caractères. Base64 encode des octets, pas des caractères : il ne peut donc pas savoir si ces octets étaient censés être de l'UTF-8, du Latin-1 ou autre chose. Si le texte d'origine était en UTF-8 et qu'il est interprété en Latin-1, les lettres accentuées deviennent des paires comme « é ». L'étape Base64 est correcte ; c'est l'interprétation qui suit qui ne l'est pas.
Pourquoi btoa() et atob() de JavaScript échouent-ils sur les caractères accentués ?
Parce qu'ils sont antérieurs à la prise en charge d'Unicode et ne gèrent que les caractères de la plage 0–255. Passer « é » à btoa() lève une InvalidCharacterError. La solution moderne consiste à convertir d'abord en octets avec TextEncoder, puis à encoder ces octets — c'est exactement ce que cet outil fait pour vous.
Y a-t-il une limite de taille ?
Aucune imposée par l'outil, mais une limite pratique imposée par votre appareil. Tout se passe en mémoire, et la copie encodée est un tiers plus volumineuse que l'entrée : les très gros fichiers ralentiront donc l'onglet avant que quoi que ce soit n'échoue vraiment. Pour des binaires de plusieurs mégaoctets, un outil en ligne de commande est mieux adapté.