daytics™
Base64 est l'un des encodages les plus utilisés sur le web, et l'un des plus mal compris. On le trouve dans les tokens JWT, les pièces jointes e-mail, les data URLs, les payloads d'API, les clés SSH et les certificats TLS. Pourtant beaucoup de développeurs le rencontrent quand quelque chose casse — un JWT qui ne se décode pas, un PNG dans CSS qui s'affiche cassé, ou une API qui refuse un upload binaire. Ce guide explique ce qu'est vraiment Base64, pourquoi il a été inventé, et quand l'utiliser ou non.
Ce que fait Base64
Au cœur, Base64 prend des données binaires arbitraires et les ré-exprime avec seulement 64 caractères ASCII imprimables et sûrs : A–Z, a–z, 0–9, plus + et /. Chaque 3 octets d'entrée (24 bits) deviennent 4 caractères de sortie (6 bits chacun). Le résultat est environ 33 % plus grand que l'entrée mais ne contient rien qui puisse perturber un système orienté texte : pas de sauts de ligne, pas de caractères de contrôle, pas d'octets non-ASCII.
Pourquoi il existe
Les premiers protocoles e-mail (SMTP, MIME) ont été conçus autour du texte ASCII 7 bits. Pour attacher un PDF ou une photo, les octets bruts étaient corrompus par les serveurs intermédiaires qui effaçaient allègrement le bit de poids fort ou inséraient un retour chariot. Base64 a résolu le problème en faisant ressembler le binaire à du texte banal. Le même problème réapparaît pour les payloads JSON, les paramètres d'URL, les en-têtes HTTP et les corps XML — partout où l'on présuppose du texte. Base64 est l'adaptateur universel.
Cas d'usage courants
- Data URLs —
data:image/png;base64,iVBORw0KGgo…incorpore une image directement dans du HTML ou CSS, utile pour les micro-icônes qui ne justifient pas une requête HTTP séparée. - JWT — l'en-tête et le payload d'un JSON Web Token sont du JSON encodé en base64url.
- MIME e-mail — les pièces jointes sont en Base64 dans les parties
Content-Transfer-Encoding: base64. - Binaire dans une API JSON — pour envoyer un fichier par un endpoint JSON, du Base64 dans un champ string garde tout valide.
- Clés SSH/TLS — le format PEM emballe du Base64 entre des lignes
BEGIN/END.
Base64 n'est pas du chiffrement
Cette section mérite d'être isolée car l'erreur est fréquente et coûteuse. Base64 n'a pas de secret : quiconque possède la chaîne encodée peut la décoder en un appel console. N'utilisez jamais Base64 pour protéger des mots de passe, des clés d'API ou des données utilisateur. Si vous voyez des identifiants « obfusqués » en Base64 dans du code source, traitez-les comme du texte clair. Utilisez un vrai chiffrement (AES, NaCl, libsodium) pour tout ce qui doit rester confidentiel.
Variantes à connaître
Le Base64 standard utilise + et /, qui ne sont pas sûrs en URL. base64url remplace ces deux caractères par - et _ et supprime le remplissage = — c'est ce qu'utilisent les JWT et les API web modernes. Il existe aussi des variantes MIME avec lignes tronquées (76 caractères) et d'anciennes implémentations incorrectes qu'on rencontre parfois. En cas de doute, vérifiez que le décodeur accepte exactement l'alphabet produit par la source.
Surcoût de taille
Trois octets entrent, quatre caractères sortent. Le surcoût exact est 4⁄3 ≈ 33 % avant remplissage ou retour à la ligne. Pour de petits actifs inline, cela en vaut la peine ; au-delà de quelques kilo-octets, préférez une requête HTTP séparée.
Quand l'utiliser
Utilisez Base64 quand des données binaires doivent traverser un canal texte-seulement et que la taille n'est pas critique. Utilisez un vrai chiffrement quand la confidentialité compte. Et pour déboguer — collez d'abord dans un décodeur Base64 avant de supposer que le token est cassé ; neuf fois sur dix le token va bien et le système qui le déballe attend un remplissage ou un alphabet différent.