Base64

Base64est un schéma d’encodage qui représente des données binaires arbitraires en utilisant 64 caractères ASCII : les lettres majuscules A-Z, les lettres minuscules a-z, les chiffres 0-9 et les symboles + et /. Complété par le caractère = pour atteindre un multiple de 4 octets. Défini dans la RFC 4648.

Trois octets d’entrée s’encodent en quatre caractères Base64, donc la forme encodée est environ 33 % plus grande que la source. L’encodage et le décodage sont tous deux déterministes et exacts — il n’y a pas de perte de qualité, juste une augmentation de taille.

Les principaux cas d’utilisation :

• Intégration de données binaires dans des protocoles ne supportant que le texte. E-mail (pièces jointes MIME), JSON (où les champs binaires ne sont pas autorisés nativement), data URI en HTML/CSS.
• JWT (JSON Web Token). Les charges utiles JWT sont encodées en Base64 (plus précisément base64url, voir ci-dessous) pour tenir en toute sécurité dans les en-têtes HTTP et les URLs.
• Stockage de binaires dans des bases de données ou des fichiers de configuration lorsque le type de colonne natif serait maladroit (par ex. les colonnes BLOB SQLite sont acceptables mais nécessitent une gestion au niveau du pilote ; une colonne TEXT contenant du Base64 est plus portable).

Base64url est une variante définie dans la même RFC qui remplace + par - et / par _. Ces deux substitutions rendent les données encodées sûres pour les URLs — ni - ni _n’ont besoin d’encodage en pourcentage dans une URL. JWT et les API web modernes utilisent base64url partout.

Encodez ou décodez dans votre navigateur avec notre outil Base64, qui gère correctement le texte UTF-8 (les primitives JavaScript btoa / atob ne le font pas).

Exemple pratique

Encodez la chaîne ASCII de trois octets “Man”. Les octets sont 0x4D 0x61 0x6E, soit en binaire 01001101 01100001 01101110. Concaténez les 24 bits et divisez-les en quatre groupes de 6 bits : 010011 010110 000101 101110 = 19, 22, 5, 46. L’alphabet Base64 mappe ces indices vers T, W, F, u — produisant “TWFu”. Aucun rembourrage nécessaire car la longueur d’entrée (3 octets) était déjà un multiple de 3. Maintenant encodez “Ma” (2 octets) : les bits sont 01001101 01100001, complétés de deux bits zéro pour obtenir 18 bits, divisés en trois groupes de 6 bits 010011 010110 000100 = 19, 22, 4 = T, W, E. Ajoutez un = pour marquer le troisième caractère manquant du groupe : “TWE=”. Le décodage inverse le processus et supprime le rembourrage. L’augmentation de taille de 33 % est exactement le rapport 4/3 — chaque 3 octets d’entrée deviennent 4 octets de sortie.

Quand et pourquoi cela importe

Base64 importe chaque fois que des données binaires doivent transiter par un canal qui altère les octets non imprimables — e-mail SMTP (conçu pour le texte sur 7 bits), chaînes de requête URL, valeurs JSON, sections CDATA XML, variables d’environnement, fichiers de configuration YAML et transferts de presse-papiers entre systèmes avec des encodages incompatibles. L’erreur classique est d’utiliser Base64 là où ce n’est pas nécessaire : un blob binaire stocké dans une colonne Postgres bytea n’a pas besoin d’encodage car le protocole gère le binaire nativement, mais le même blob inséré via un littéral de chaîne SQL en a besoin. La deuxième erreur classique est l’opposé — intégrer un JPEG comme data URI dans CSS en utilisant Base64 pour éviter une requête HTTP, puis découvrir que le fichier gonflé est plus volumineux que les économies réseau sur des connexions HTTP/2 multiplexées. Les politiques modernes d’intégration d’images fixent généralement la limite autour de 4 à 8 Ko. Référence : RFC 4648 — Encodages de données Base16, Base32 et Base64.

Rembourrage et les caractères "=" en fin : comme Base64 emballe chaque 3 octets d’entrée en 4 caractères de sortie, les entrées dont la longueur n’est pas un multiple de 3 produisent 1 ou 2 caractères de rembourrage en fin. YQ==se décode en un seul octet ("a") ; YWI=se décode en deux octets ("ab") ; YWJjse décode en trois octets ("abc") sans rembourrage. De nombreux parseurs Base64 acceptent les entrées sans rembourrage même si la conformité stricte RFC l’exige — base64url dans les contextes JWT omet délibérément le rembourrage. Vérifiez toujours si votre paire encodeur/décodeur s’accorde sur le rembourrage, en particulier lors du raccordement d’implémentations strictes et tolérantes.

Pourquoi Base64 n’est pas du chiffrement :Base64 est un mappage déterministe que chacun peut inverser sans clé. Coller une chaîne Base64 dans un décodeur en ligne révèle immédiatement le texte en clair. C’est un encodage (un changement de représentation), pas un chiffrement (une transformation de confidentialité). Stocker des mots de passe, des clés API ou des données personnelles en Base64 dans tout fichier pouvant être lu par un attaquant est fonctionnellement équivalent à les stocker en texte clair. Pour la confidentialité, utilisez un chiffrement approprié (AES-GCM, ChaCha20-Poly1305) avec une vraie gestion des clés avant tout encapsulation Base64. Référence : RFC 4648 — Encodages de données Base16, Base32 et Base64.