Qu'est-ce que l'encodage Base64 et quand l'utiliser

Si vous travaillez avec des API, des systèmes d'e-mail ou du développement web, vous avez croisé Base64 même sans le reconnaître. Ces longues chaînes de lettres et chiffres qui ressemblent à du charabia au début d'une pièce jointe e-mail, dans une URL data: en CSS, ou au segment du milieu d'un jeton JWT ? C'est du Base64. C'est l'une des pièces de plomberie d'Internet les plus anciennes et les plus discrètement porteuses, et presque chaque logiciel que vous utilisez s'appuie dessus quelque part.

Une brève histoire de Base64

Base64 fait partie d'une famille appelée « radix-64 » ou « encodages imprimables », dont le rôle est de représenter des octets quelconques en n'utilisant que le petit alphabet de caractères qu'un système textuel est garanti de laisser passer intacts. Le membre le plus largement utilisé en premier est uuencode, écrit par Mary Ann Horton à UC Berkeley vers 1980 pour envoyer des fichiers binaires par Usenet et e-mail à une époque où ces systèmes corrompaient tout ce qui dépassait l'ASCII 7 bits.

L'alphabet Base64 lui-même a été d'abord standardisé dans la RFC 989 (1987) pour Privacy-Enhanced Mail (PEM), une première tentative d'e-mail signé et chiffré. PEM est mort, mais son schéma d'encodage a survécu et a été canonisé dans la RFC 1421 (1993) puis dans la spécification MIME (RFC 1521 et 1522 en 1993, révisées en RFC 2045 à 2049 en 1996). MIME a fait de Base64 la façon par défaut d'attacher des fichiers binaires à un e-mail, et de là l'encodage s'est diffusé à presque tout transport texte sur internet.

En 2006, l'IETF a consolidé les définitions Base64 éparses dans la RFC 4648, qui définit Base64, Base32 et Base16 dans un même document. La RFC 4648 a aussi défini la variante URL-safe en section 5, qui a remplacé les deux caractères non-URL-friendly (+ et /) par - et _. Les JSON Web Tokens (RFC 7519, 2015) ont standardisé sur Base64 URL-safe sans le padding. Aujourd'hui, chaque pièce jointe e-mail, chaque certificat encodé en PEM, chaque URL data:, chaque JWT et chaque frontière de téléversement multipart dépend de Base64.

Comment Base64 fonctionne : les maths

Base64 prend trois octets d'entrée (24 bits) et les réécrit en quatre caractères de sortie (6 bits chacun), avec un alphabet à 64 symboles. La correspondance est fixe :

Donc Hello devient :

• Octets ASCII : 0x48 0x65 0x6C 0x6C 0x6F (5 octets)
• Binaire : 01001000 01100101 01101100 01101100 01101111
• Regroupé en blocs de 6 bits : 010010 000110 010101 101100 011011 000110 1111
• Le dernier bloc est court, complété par des zéros : 010010 000110 010101 101100 011011 000110 111100
• Table : S G V s b G 8 (7 caractères seulement pour 6 groupes de 6 bits = 36 bits, padding pour les 4 manquants)
• Padding : ajouter = pour arrondir à un multiple de 4 caractères : SGVsbG8=

La sortie est toujours un multiple de 4 caractères. Si la longueur d'entrée modulo 3 vaut 1, vous obtenez deux = de padding ; si elle vaut 2, vous obtenez un = ; si elle vaut 0, pas de padding. Le padding est parfois retiré (notamment en JWT et dans les fragments d'URL) et les décodeurs doivent tolérer cela.

L'overhead de 33 % vient de cette expansion 3-vers-4 : chaque 3 octets d'entrée deviennent 4 caractères de sortie, soit un tiers de plus. Il n'y a pas moyen de le réduire sans changer d'alphabet (Base85 / Ascii85 n'augmente que de 25 % en utilisant 85 caractères imprimables, au prix d'un encodeur plus complexe).

Cas d'usage courants

Pièces jointes e-mail. SMTP, le protocole qui transporte 95 % des e-mails entre serveurs, a été conçu en 1982 (RFC 821) pour de l'ASCII 7 bits. Toute pièce jointe binaire que vous envoyez (une image, un PDF, un ZIP) est encodée en Base64 par votre client mail avant transmission et décodée par celui du destinataire. Les en-têtes MIME dans l'e-mail indiquent au destinataire quelles parties sont en Base64 et quelles parties sont en texte brut.

URL data dans HTML et CSS. Une URL data:image/png;base64,iVBORw0KGgo... intègre un fichier binaire directement dans le document. Utile pour de petites icônes sous 1-2 Ko, où la requête HTTP économisée pèse plus lourd que l'overhead de 33 % et la perte du cache.

Charges utiles d'API. Quand une API JSON ou XML doit accepter une valeur binaire (un fichier uploadé, une signature, une photo de profil), le motif standard est d'encoder les octets en Base64 et de les transporter comme champ chaîne. Le récepteur les décode côté serveur. C'est comme ça que l'entrée image d'OpenAI fonctionne, comme Stripe reçoit les uploads de fichiers, et comme la plupart des fonctions cloud acceptent l'entrée binaire.

HTTP Basic Authentication. L'en-tête Authorization: Basic <token> porte une paire username:password encodée en Base64 (RFC 7617). C'est de l'encodage, pas du chiffrement : quiconque voit l'en-tête voit le mot de passe. Basic Auth exige HTTPS pour cette raison.

Certificats et clés. Les fichiers PEM (-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----) enveloppent un blob d'octets ASN.1 encodés en DER, encodés en Base64. Chaque certificat TLS, chaque fichier de clé SSH, chaque certificat de signature de code est du Base64 dans une enveloppe PEM.

Jetons JWT. Un JWT est composé de trois segments Base64 URL-safe séparés par des points : <header>.<payload>.<signature>. L'encodage Base64 permet à un JWT de voyager en sécurité dans les en-têtes, les URL et les cookies.

Comment encoder et décoder

1. Choisissez encoder ou décoder : sélectionnez le sens de conversion.
2. Collez du texte ou téléversez un fichier : entrez le texte directement ou glissez-déposez un fichier (jusqu'à 5 Mo pour l'encodage côté navigateur).
3. Choisissez la variante : Base64 standard pour les e-mails et certificats, URL-safe pour JWT et fragments d'URL. L'outil utilise standard par défaut.
4. Copiez le résultat : la sortie se met à jour instantanément. Copiez-la dans votre presse-papiers, ou utilisez le bouton de téléchargement pour les sorties longues.

Variantes de Base64

Plusieurs encodages de type Base64 existent pour des situations spécifiques :

La plupart du temps vous voulez Base64 standard ou URL-safe. Les autres apparaissent dans des protocoles spécifiques.

Quand utiliser Base64

Utilisez-le quand :

• Vous devez intégrer une petite image (sous 5 Ko) directement dans HTML ou CSS, en économisant une requête HTTP.
• Une API exige des données binaires comme chaîne de texte dans une charge JSON ou XML.
• Vous faites passer des données binaires par un système qui ne supporte que le texte (e-mail, entrées de log, paramètres de requête).
• Vous encodez un JWT, un certificat, une clé ou tout blob binaire structuré.
• Vous voulez une représentation chaîne déterministe et autonome que n'importe quel langage peut décoder.

Ne l'utilisez pas quand :

• Le fichier est gros. Base64 ajoute 33 % d'overhead, empêche le cache navigateur du binaire comme ressource séparée et force le blob entier à travers le parseur de page.
• Vous voulez de la sécurité. Base64 n'est pas du chiffrement ; il est trivialement réversible.
• Vous pouvez servir le fichier normalement. Un simple <img src="photo.jpg"> est plus efficace qu'une URL data Base64 pour tout ce qui dépasse quelques Ko.
• Vous voulez une représentation compacte. Hex est plus simple si la taille n'importe pas ; Base85 est plus dense si elle importe.

Pièges courants

• Confondre encodage et chiffrement. Base64 est réversible par n'importe qui en millisecondes. Passer un « secret » par Base64 ne le protège de rien d'autre que d'un coup d'œil par-dessus l'épaule.
• La pénalité de taille de 33 %. Une image de 1 Mo devient une chaîne de 1,33 Mo, et les URL data en ligne sont téléchargées avec le HTML parent à chaque visite, sans cache séparé.
• Sauts de ligne en MIME Base64. La variante MIME insère \r\n tous les 76 caractères. Si vous collez du MIME Base64 dans une valeur JSON ou une URL, ça échoue ; retirez d'abord les sauts de ligne.
• Padding retiré en JWT. JWT utilise Base64 URL-safe avec le = de padding retiré. Une bibliothèque qui exige strictement le padding rejettera des JWT valides ; une qui n'en produit pas créera des jetons que d'autres bibliothèques rejettent. La RFC 7515 mandate « sans padding » pour le standard JWS.
• Confusion URL-safe vs standard. Décoder une chaîne URL-safe avec un décodeur standard échoue sur les caractères - et _ ; décoder une chaîne standard avec un décodeur URL-safe échoue sur les + et /.
• Gestion de l'entrée Unicode. Base64 opère sur des octets, pas des caractères. Si vous encodez en Base64 une chaîne d'emojis UTF-8, vous devez d'abord choisir un encodage d'octets (presque toujours UTF-8). Différents runtimes ont différents défauts ; spécifiez-le explicitement.
• Décodeurs streaming partiels. Un décodeur Base64 en flux correctement implémenté attend des groupes de 4 caractères d'entrée avant d'émettre 3 octets de sortie. Les implémentations naïves qui décodent un caractère à la fois produisent du charabia.
• Blancs et BOM en fin. Certains éditeurs ajoutent un saut de ligne ou un BOM UTF-8 quand vous sauvegardez. Cet octet supplémentaire change la sortie Base64. Diffez votre résultat encodé contre une source amont si vous voyez des mismatches inattendus.
• + interprété comme espace dans les URL. Le + de Base64 standard devient ` ` (espace) quand un parseur d'URL le décode en pourcent. C'est exactement pour ça que Base64 URL-safe existe.

Alternatives et encodages voisins

Base64 est le défaut, pas la seule option. Le bon choix dépend du canal et du budget de taille.

Pour la plupart des cas du quotidien, la réponse est Base64 (standard ou URL-safe). Pour les uploads binaires sur HTTP, la bonne réponse est généralement multipart/form-data, qui n'encode pas du tout.

Confidentialité et l'encodeur

L'encodeur et décodeur Base64 tourne entièrement dans votre navigateur. Le texte ou fichier que vous saisissez est traité par JavaScript sur votre appareil, le résultat est rendu sur la page, et rien n'est envoyé à un serveur. Rien n'est journalisé, rien n'est stocké après que vous quittez la page, et aucun tag d'analytics ne voit le contenu. Pour les choses que vous pourriez encoder en Base64 (certificats PEM, clés privées, charges utiles JWT de systèmes de production, brouillons de requêtes API avec de vraies données client), ce flux strictement local est le bon défaut. L'outil entier peut tourner hors-ligne une fois la page chargée, ce que vous pouvez vérifier en coupant le réseau et en ré-encodant la même entrée.