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.
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.
