Base64 expliqué : à quoi il sert, et pourquoi il ne chiffre rien

Base64 est partout dans le logiciel : pièces jointes d’e-mails, images intégrées dans le CSS, en-tête Authorization de l’authentification HTTP Basic et parties d’un JWT. Il a une seule mission : écrire n’importe quelle donnée, y compris des octets binaires, avec uniquement des caractères de texte sûrs.

Comment ça marche

Base64 prend les données trois octets (24 bits) à la fois et les découpe en quatre groupes de 6 bits. Chaque groupe est un nombre de 0 à 63 qui correspond à l’un de 64 caractères : A-Z, a-z, 0-9, + et /. Quand l’entrée ne se divise pas en groupes de trois, des signes = complètent la fin.

Texte   M        a        n
Octets  01001101 01100001 01101110
6 bits  010011 010110 000101 101110
Base64  T      W      F      u       →  TWFu

Pourquoi il existe

Beaucoup de systèmes anciens, l’e-mail en tête, ont été conçus pour du texte et pouvaient abîmer des octets quelconques. Base64 transforme tout en caractères ordinaires qui traversent ces canaux sans modification. Le prix, c’est la taille : 3 octets deviennent 4 caractères, donc les données encodées pèsent environ 33 % de plus.

Ce n’est pas du chiffrement

Il n’y a pas de clé. N’importe qui décode du Base64 instantanément, il ne cache donc rien. Un mot de passe dans un en-tête Basic (dXNlcjpwYXNz, c’est simplement user:pass) est aussi exposé que du texte en clair. Protégez les secrets avec HTTPS et un vrai chiffrement, et ne considérez jamais Base64 comme une mesure de sécurité.

Les variantes que vous croiserez

Base64url remplace + et / par - et _ et supprime généralement le remplissage, pour un résultat sûr dans les URL et les noms de fichiers ; les JWT l’utilisent. Les data URI placent les données encodées directement dans le code, comme data:image/png;base64,iVBOR…, ce qui évite une requête pour de toutes petites images mais alourdit les plus grandes.

La taille en chiffres

La longueur encodée est de 4 × ceil(n / 3) caractères pour n octets : le surcoût est donc d’environ 33 %, plus les retours à la ligne si l’encodeur en ajoute.

Image de 100 Ko        →  environ 133 Ko de Base64
Pièce jointe de 1 Mo   →  environ 1,33 Mo (plus les retours à la ligne)

Pourquoi le décodage échoue

• Le remplissage manque : certains systèmes suppriment les signes = finaux, et les décodeurs stricts refusent alors l’entrée. Ajoutez des = jusqu’à ce que la longueur soit un multiple de 4.
• Le mauvais alphabet : Base64url utilise - et _ au lieu de + et /. Décodez-le avec un décodeur Base64url, ou remplacez d’abord les caractères.
• Retours à la ligne et espaces : l’e-mail (MIME) coupe le Base64 tous les 76 caractères. La plupart des décodeurs les ignorent, mais pas tous.
• Un texte dans le mauvais encodage : le décodage donne des octets. S’il s’agissait de texte UTF-8 lu comme du Latin-1, les accents et l’hébreu deviennent illisibles.

Le piège de btoa en JavaScript

La fonction btoa() intégrée au navigateur n’accepte que les caractères Latin-1 et lève une erreur avec l’hébreu, le chinois ou les emojis. Encodez d’abord le texte en octets UTF-8, par exemple avec TextEncoder, puis en Base64.

Quand l’utiliser, et quand l’éviter

Base64 est le bon outil quand des données binaires doivent passer par un canal prévu pour du texte : charges JSON et XML, e-mail, URI de données et en-têtes HTTP. C’est le mauvais outil pour cacher des données, pour les réduire (elles grossissent toujours) et pour stocker de gros fichiers dans une base de données, où une colonne binaire ou un stockage d’objets est plus petit et plus rapide. Si le destinataire accepte des octets bruts, envoyez des octets bruts.

Essayez

L’encodeur Base64 de 4Dev convertit le texte en Base64 pendant que vous tapez. Il utilise l’UTF-8, si bien que les accents, la cédille, les emoji et tout autre texte non anglais sont encodés correctement. Pour le chemin inverse, utilisez le décodeur Base64.

Ouvrir l’encodeur Base64