Base64 est un de ces formats que chaque développeur a utilisé mais que peu peuvent expliquer sans hésiter. Il ressemble à des caractères aléatoires. Il rend les données plus volumineuses. Et pourtant, c’est l’épine dorsale des pièces jointes e-mail, des payloads JWT, des images intégrées en CSS et de dizaines d’autres protocotes qui doivent déplacer des données binaires via des canaux texte uniquement.
La version courte : Base64 encode des données binaires arbitraires en caractères ASCII imprimables. La version longue implique un alphabet de 64 caractères, des règles de remplissage et quelques variantes qui piègent les gens en production.
Pourquoi Base64 existe
De nombreux systèmes ont été conçus pour ne transporter que du texte — e-mail (SMTP), URLs, XML, JSON. Si vous voulez envoyer un fichier binaire via l’un de ces canaux, vous avez besoin d’un moyen de représenter des octets en caractères. Base64 résout cela en associant chaque 3 octets d’entrée à 4 caractères de sortie, en n’utilisant que des caractères qui sont sûrs dans pratiquement tous les protocoles texte.
Le compromis : Base64 augmente la taille des données d’environ 33%. Une image de 1 Ko devient environ 1,3 Ko de texte. Pour la plupart des cas d’utilisation, c’est acceptable. Pour les systèmes à haut débit, cela compte, et vous verrez des alternatives comme Base85 ou des protocoles binaires bruts.
Les 64 caractères
L’alphabet est :
A-Z (26 caractères)
a-z (26 caractères)
0-9 (10 caractères)
+ / (2 caractères)C’est 64 caractères au total, d’où le nom. Le caractère = est utilisé pour le remplissage lorsque la longueur de l’entrée n’est pas un multiple de 3 octets.
Chaque caractère de l’alphabet est un ASCII imprimable, ce qui signifie que la sortie de Base64 peut circuler par e-mail, apparaître dans des chaînes JSON, se trouver dans des attributs HTML et survivre aux systèmes qui pourraient altérer le binaire brut.
Comment fonctionne le codage
Prenez trois octets d’entrée. Chaque octet a 8 bits, donc vous avez 24 bits au total. Base64 divise ces 24 bits en quatre groupes de 6 bits. Chaque groupe de 6 bits est associé à un caractère de l’alphabet :
000000→A000001→B- …
111111→z
C’est tout. Le codage est une transformation simple au niveau des bits sans clé, sans sel et sans secret. N’importe qui peut décoder Base64 en inversant la table de recherche.
Remplissage
Si la longueur de l’entrée n’est pas un multiple de 3, le remplissage comble le vide :
- 1 octet restant → 2 caractères Base64 +
== - 2 octets restants → 3 caractères Base64 +
= - 0 octet restant → pas de remplissage
Les caractères de remplissage ne portent pas de données. Ils existent pour que la longueur de la sortie soit toujours un multiple de 4, ce que de nombreux analyseurs attendent.
Variantes
Tout le Base64 n’est pas identique :
- Base64 standard (
A-Za-z+/=) — par défaut, utilisé dans les e-mails MIME et la plupart des protocoles. - Base64 sûr pour les URLs (
A-Za-z-_) — remplace+par-et/par_, supprime le remplissage. Utilisé dans les JWT, les paramètres d’URL et les noms de fichiers. - Base64 sans remplissage — certains systèmes omettent les caractères
=. La sortie est plus courte mais certains analyseurs échouent avec.
Lorsque vous déboguez un JWT ou un data URI et que la décodification échoue, la première chose à vérifier est si l’encodeur a utilisé le Base64 sûr pour les URLs ou le Base64 standard. Un - au milieu de ce que vous attendiez être une chaîne Base64 standard est le signe révélateur.
Où les développeurs rencontrent réellement Base64
Pièces jointes e-mail. MIME (RFC 2045) utilise Base64 pour encoder les pièces jointes binaires. Si vous avez déjà vu un fichier .eml avec de longues chaînes de caractères aléatoires, c’est du contenu codé en Base64.
Payloads JWT. Les trois parties d’un JWT (en-tête, payload, signature) sont chacune encodées en Base64 sûr pour les URLs. Lorsque vous décodez un JWT, vous inversez l’encodage Base64url sur chaque segment.
Data URIs. data:image/png;base64,iVBOR... vous permet d’intégrer une image directement en HTML ou CSS. Les octets de l’image sont codés en Base64 pour qu’ils puissent apparaître dans un attribut texte.
APIs. Certaines APIs acceptent ou retournent des données binaires codées en Base64 (téléchargement de fichiers, traitement d’images, signatures cryptographiques). C’est moins courant maintenant que la plupart des APIs supportent les données de formulaire multipart, mais cela apparaît encore.
Intégrations. Les modèles d’apprentissage automatique stockent parfois des intégrations sous forme de chaînes Base64 en JSON. Ce n’est pas idéal pour les performances, mais c’est pratique pour le transport.
Quand NE PAS utiliser Base64
Ne l’utilisez pas pour le chiffrement. Base64 est un codage, pas du chiffrement. N’importe qui peut le décoder. Si vous mettez des données sensibles en Base64, vous les obscurez seulement, vous ne les protégez pas.
Ne l’utilisez pas pour la compression. Base64 rend les données plus volumineuses, pas plus petites. Si vous encodez en Base64 des données déjà compressées (comme un fichier .gz), vous ajoutez de la surcharge sans bénéfice.
Ne l’utilisez pas dans les chemins critiques en performances. Le codage/décodification ajoute du temps CPU et augmente la taille du payload. Pour les APIs internes à haute fréquence, utilisez des protocoles binaires (protobuf, msgpack) à la place.
N’oubliez pas la variante. Si vous générez du Base64 pour une URL ou un JWT, utilisez le Base64 sûr pour les URLs. Si vous générez pour l’e-mail ou le transport général, utilisez le Base64 standard. Les mélanger cause une corruption silencieuse des données.
Référence rapide
| Scénario | Variante | Remplissage |
|---|---|---|
| JWT | Sûr pour les URLs | Non |
| E-mail / MIME | Standard | Oui |
| Data URI | Standard | Optionnel |
| Paramètre d’URL | Sûr pour les URLs | Non |
| Transport général | Standard | Oui |
Essayez
Si vous avez une chaîne Base64 à décoder ou des données binaires à encoder, utilisez un outil basé sur navigateur pour que la conversion se fasse localement — vos données ne sont envoyées à aucun serveur pour quelque chose d’aussi simple.