Base64 est l’un des encodages texte les plus répandus en informatique : on le trouve dans les pièces jointes de courriel, les URI de données, les jetons OAuth, les réponses d’API, les bibliothèques cryptographiques et bien d’autres endroits. Pourtant, beaucoup de développeurs ne savent pas précisément comment il fonctionne, quelle variante ils utilisent, ni quelles garanties il offre. Les sections suivantes présentent son origine dans les infrastructures de messagerie des années 1990, le fonctionnement de l’encodage bit par bit et les cas où Base64 convient ou est mal utilisé.
Pourquoi Base64 existe : le problème des courriels dans les années 1990
Base64 a été normalisé en 1993 dans le cadre de la spécification MIME (RFC 1421, puis RFC 2045), mais le problème est plus ancien. Les protocoles de courriel des années 1970 et 1980 supposaient que chaque octet d’un message était un caractère ASCII imprimable sur 7 bits, car les serveurs SMTP et les routeurs de l’époque supprimaient ou corrompaient les octets dont le bit de poids fort était activé. Cela convenait au texte anglais, mais pas aux pièces jointes binaires : images, exécutables, texte non ASCII et autres données. MIME a introduit plusieurs encodages pour résoudre ce problème (Quoted-Printable pour le contenu principalement textuel, Base64 pour les données binaires quelconques). Base64 s’est rapidement imposé, car il traite toute séquence d’octets sans cas particulier. Le problème s’est étendu à tous les protocoles qui attendent du texte : stocker des données binaires en JSON ou XML, les intégrer à des URL, les transmettre dans des chaînes de commandes ou les écrire dans le code source. Base64 est une solution sûre parce qu’il n’utilise que 64 caractères traités de manière uniforme par les systèmes texte. Son coût est une surcharge de taille de 33 %, contrepartie inhérente à cette compatibilité.
Fonctionnement de l’encodage
Base64 traite des groupes de 3 octets d’entrée (24 bits), répartit ces 24 bits en 4 groupes de 6 bits et associe chaque groupe à un caractère de l’alphabet de 64 caractères (A–Z, a–z, 0–9, ainsi que `+` et `/` en Base64 standard, ou `-` et `_` dans la variante compatible avec les URL). Six bits représentent 64 valeurs (2⁶), d’où le nom. Si la longueur d’entrée n’est pas un multiple de 3 octets, le dernier groupe est complété par des bits nuls et la sortie par des caractères `=` pour conserver des blocs de 4 caractères : un octet restant donne 2 caractères suivis de `==`, et deux octets restants donnent 3 caractères suivis de `=`. Le décodage inverse ce processus : le remplissage `=` est retiré, les caractères sont regroupés par quatre puis reconvertis en 24 bits, eux-mêmes répartis en octets. Les variantes courantes comprennent Base64url (alphabet compatible avec les URL, sans remplissage), Base64 avec retour à la ligne tous les 64 ou 76 caractères pour MIME, ainsi que Base32 et Base16.
Quand choisir Base64 — et quand l’éviter
Base64 convient lorsqu’il faut intégrer des données binaires dans un support textuel : images en ligne dans HTML ou CSS avec une URI de données, charges binaires en JSON ou XML, jetons OAuth, cookies signés, pièces jointes de courriel ou clés cryptographiques dans des fichiers de configuration. Base64 ne chiffre pas les données : toute personne qui possède la chaîne peut la décoder en quelques millisecondes. Ne l’utilisez jamais pour protéger des données sensibles ; utilisez un chiffrement tel qu’AES-GCM ou ChaCha20-Poly1305, ou un hachage de mot de passe tel que bcrypt ou Argon2. Base64 ne compresse pas non plus : il ajoute environ 33 % de surcharge. Pour transférer efficacement de gros fichiers, utilisez gzip ou Brotli avant l’encodage si Base64 est nécessaire, ou évitez Base64 si le transport accepte déjà les données binaires. Enfin, Base64 n’est pas une méthode d’obfuscation sécurisée : masquer une URL ou une clé API dans du JavaScript côté client ne protège rien contre une personne qui ouvre les outils de développement du navigateur.