Qu'est-ce que le Base64 ?
Le Base64 est un schéma d'encodage qui convertit des données binaires en texte ASCII en utilisant 64 caractères (A–Z, a–z, 0–9, + et /). Il est couramment utilisé pour intégrer des images en HTML/CSS, transmettre du binaire dans du JSON ou des en-têtes HTTP, et stocker du binaire dans des formats texte.
Base64 URL-safe
Le Base64 standard utilise +, / et = — qui ont tous une signification spéciale dans les URL. La variante URL-safe les remplace par - et _ et supprime le padding, ce qui la rend sûre dans les query strings, les tokens JWT et similaires.
Confidentialité
L'encodage et le décodage se font entièrement dans votre navigateur. Vos données ne sont jamais envoyées à un serveur.
Base64 en pratique
Base64 sert partout où des données binaires doivent voyager dans un canal qui n'accepte que du texte. Les cas les plus fréquents :
- Image en data URI —
<img src="data:image/png;base64,iVBORw0K…"> intègre une petite image directement dans le HTML ou le CSS, sans fichier séparé ni requête réseau. Utile pour les icônes ou les e-mails.
- En-tête d'authentification HTTP Basic —
Authorization: Basic dXNlcjpwYXNz est simplement user:pass encodé en Base64. À n'utiliser que sur HTTPS : ce n'est pas chiffré.
- Inspecter un JWT — collez un segment de token (entre les points) dans le décodeur pour lire le header ou le payload en clair.
- Certificats et clés PEM — le bloc entre
-----BEGIN----- et -----END----- est du Base64. Décodez-le pour examiner la structure DER.
Base64 n'est pas du chiffrement
C'est l'erreur de sécurité la plus répandue. Base64 est entièrement réversible par n'importe qui, sans clé — c'est un simple changement d'alphabet, pas une protection. N'« encodez » jamais un secret en Base64 en pensant le cacher : pour protéger une donnée, il faut un vrai chiffrement (AES, par exemple), et Base64 sert seulement, le cas échéant, à transporter le résultat chiffré.
Questions fréquentes
Pourquoi mon Base64 fait-il 33 % de plus que l'original ?
Base64 regroupe les octets par paquets de 3 et les représente avec 4 caractères ASCII. Trois octets (24 bits) deviennent 4 caractères (32 bits), soit un overhead de 4/3 ≈ 1,333. Une image de 100 Ko encodée en Base64 pèsera environ 136 Ko. Ce surcoût est inévitable : c'est le prix à payer pour représenter des données binaires dans un alphabet textuel de 64 symboles.
Base64 vs hexadécimal : quand utiliser lequel ?
L'hexadécimal représente chaque octet par 2 caractères (overhead de 100 %), Base64 avec 1,33 caractère en moyenne (overhead 33 %). Base64 est donc plus compact. L'hex est plus lisible pour déboguer des données courtes (hash SHA-256, adresses mémoire) car chaque nibble correspond directement. Pour transporter des données binaires volumineuses (images, certificats, clés), préférez Base64. Pour afficher un hash, l'hex est plus pratique.
Pourquoi mon JWT contient-il des points (.) entre les segments Base64 ?
Un JWT (JSON Web Token) est structuré en trois parties séparées par des points : header.payload.signature. Chaque partie est encodée indépendamment en Base64url (variante sans + ni /, avec - et _ à la place, et sans padding =). Les points servent de délimiteurs fixes entre les trois segments. C'est une convention de format définie dans la RFC 7519, pas une particularité de Base64 lui-même.
Mon Base64 contient des espaces ou des retours à la ligne : est-ce normal ?
Oui, dans le contexte MIME (emails, certificats PEM). La RFC 2045 impose un retour à la ligne tous les 76 caractères pour la compatibilité avec les anciens systèmes. Un certificat .pem commence par -----BEGIN CERTIFICATE----- et contient du Base64 sur 64 colonnes. Si vous décodez du Base64 provenant d'un email ou d'un certificat, retirez les espaces et sauts de ligne avant décodage, ou utilisez une bibliothèque qui le gère automatiquement.
Base64 standard vs URL-safe : comment savoir lequel utiliser ?
La règle est simple : si votre Base64 transite dans une URL (paramètre GET, segment de chemin, cookie) ou dans un contexte JSON/JWT, utilisez Base64url (RFC 4648 §5) avec - à la place de + et _ à la place de /. Si vous encodez pour un email MIME, un certificat PEM ou un contexte purement textuel hors URL, utilisez le Base64 standard. Les deux sont identiques sauf pour ces deux caractères et le padding facultatif en Base64url.
