Le Base64 expliqué : à quoi il sert, et quand l'éviter

Le Base64 réécrit des données binaires quelconques à l'aide de 64 caractères seulement, qui traversent sans dommage n'importe quel canal texte. C'est un format de transport, pas une mesure de sécurité : n'importe qui peut l'inverser en une seconde, et le résultat pèse environ un tiers de plus que l'original. On le rencontre dans les pièces jointes des e-mails, les data URL en CSS, les API JSON, les jetons JWT et l'authentification HTTP Basic.

La méthode rapide : collez votre texte ou déposez un fichier dans l'encodeur Base64, ou faites l'inverse avec le décodeur Base64. Les deux fonctionnent dans le navigateur : rien n'est envoyé.

Comment ça marche

Beaucoup de protocoles ont été conçus pour transporter du texte, pas des octets quelconques. Un octet peut prendre 256 valeurs, et certaines d'entre elles — octets nuls, caractères de contrôle, tout ce qui dépasse 127 — sont déformées, tronquées ou réinterprétées en chemin.

Le Base64 contourne le problème en ignorant les frontières d'octets et en regroupant les bits autrement. On prend 3 octets, soit 24 bits, et on les découpe en quatre groupes de 6 bits. Six bits représentent 64 valeurs, et chaque valeur correspond à un caractère de l'alphabet A–Z, a–z, 0–9, + et /. Trois octets en entrée, quatre caractères en sortie, à chaque fois.

Quand la longueur d'entrée n'est pas un multiple de 3, le dernier groupe est complété par des = pour que la sortie reste un multiple de 4 :

Entrée	Octets	Sortie	Remplissage
Man	3	TWFu	aucun
Ma	2	TWE=	un =
M	1	TQ==	deux =
Hello, world!	13	SGVsbG8sIHdvcmxkIQ==	deux =

L'augmentation de taille, précisément

Quatre caractères pour trois octets, c'est un rapport de 4 ÷ 3 = 1,3333 : la sortie Base64 est donc 33,33 % plus lourde que l'entrée. Ce chiffre n'est exact que si la longueur d'entrée est un multiple de 3 ; le remplissage pénalise les chaînes courtes. Hello, world! fait 13 octets et donne 20 caractères, soit 54 % de plus.

Entrée	Encodé	Augmentation
2 Kio (2 048 octets)	2 732 caractères	33,40 %
40 Kio (40 960 octets)	54 616 caractères	33,34 %
1 Mio (1 048 576 octets)	1 398 104 caractères	33,33 %

L'e-mail en rajoute un peu. Le format MIME coupe le Base64 tous les 76 caractères, et chaque saut de ligne coûte 2 octets de plus, soit 2,63 % supplémentaires. Une pièce jointe de 1 Mio voyage donc sous la forme d'environ 1 434 898 octets, à peu près 37 % de plus que le fichier sur le disque. C'est pourquoi une limite de 20 Mo bloque des pièces jointes nettement plus petites que 20 Mo.

Pour convertir ces unités, le convertisseur de stockage gère les octets, Kio, Ko, Mio et Mo.

Le texte doit d'abord devenir des octets

Le Base64 encode des octets : un texte doit donc être converti en octets au préalable, en pratique en UTF-8. café compte quatre caractères mais cinq octets en UTF-8, car le é en occupe deux, et donne Y2Fmw6k=.

C'est exactement là que la fonction btoa() du navigateur échoue : elle n'accepte que des points de code jusqu'à 255, si bien que les lettres accentuées et les émojis déclenchent une erreur ou, pire, sont silencieusement corrompus si l'on contourne mal le problème. L'encodeur proposé ici convertit d'abord en UTF-8, ce que l'on veut presque toujours. Au décodage, il faut refaire les deux étapes en sens inverse : les octets depuis le Base64, puis le texte depuis l'UTF-8.

Le Base64URL

Le Base64 standard utilise + et /, qui ont tous deux un sens particulier dans une URL, ainsi que =, séparateur de chaîne de requête. Le Base64URL est le même algorithme avec deux substitutions — + devient -, / devient _ — et le remplissage généralement supprimé. La suite d'octets qui donne +//+ en Base64 standard donne -__- en Base64URL.

Les jetons JWT emploient le Base64URL pour leurs trois parties. C'est pourquoi l'en-tête {"alg":"HS256","typ":"JWT"} apparaît toujours sous la forme eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9, et pourquoi le décodeur JWT affiche le contenu de n'importe quel jeton sans disposer d'une clé.

Le Base64URL n'est pas l'encodage pour cent. Pour rendre une chaîne quelconque utilisable dans une URL ou un corps de formulaire, c'est l'encodeur d'URL qu'il vous faut.

Les data URL

Une data URL intègre un fichier directement dans le balisage ou la feuille de style : data:image/png;base64,iVBORw0KGgo…. Le navigateur la décode sans requête supplémentaire. Les contreparties sont réelles :

• Le contenu pèse 33 % de plus et ne peut pas être mis en cache séparément du document qui le contient.
• Répéter la même icône dans trois feuilles de style revient à l'envoyer trois fois.
• Les règles de Content Security Policy bloquent souvent les sources data:, en particulier pour les scripts et les cadres.

L'usage raisonnable consiste à n'intégrer que de très petits éléments, de l'ordre de quelques kilo-octets, et à servir le reste comme un fichier normal. Le SVG est souvent une meilleure réponse qu'un PNG en Base64, puisqu'il s'écrit directement dans le HTML sans encodage.

Le Base64 n'est pas du chiffrement

Le décodage ne demande ni clé, ni mot de passe, ni effort. Le Base64 ne cache rien.

L'authentification HTTP Basic envoie identifiant:mot de passe en Base64 dans un en-tête, ce qui n'est pas une protection : c'est précisément pour cela qu'elle ne doit s'utiliser qu'en HTTPS. La charge utile d'un JWT est signée, pas chiffrée : quiconque détient le jeton peut en lire le contenu.

Si vous cherchez vraiment l'une des propriétés que l'on prête parfois au Base64 :

Ce que vous voulez	Ce qu'il faut utiliser
La confidentialité	Du chiffrement (TLS en transit, AES ou équivalent au repos)
La preuve qu'un fichier n'a pas changé	Une empreinte comme SHA-256 : voir le générateur d'empreintes et le guide Vérifier un téléchargement avec une somme de contrôle
Une valeur sûre dans une URL	L'encodage pour cent, ou le Base64URL
Un contenu plus léger	La compression, avant l'encodage s'il est indispensable

Questions fréquentes

Le Base64 compresse-t-il quelque chose ? Non, c'est l'inverse. Si le poids compte, compressez d'abord et encodez les octets compressés.

Pourquoi une chaîne Base64 se termine-t-elle par = et une autre non ? Le remplissage ne dépend que de la longueur d'entrée modulo 3. Le Base64URL l'omet souvent entièrement, et les décodeurs s'en accommodent en général.

Peut-on mettre du Base64 dans du JSON ? Oui, c'est même l'un de ses principaux usages, puisqu'une chaîne JSON ne peut pas contenir d'octets quelconques. Vérifiez le résultat avec le guide Formater, valider et réparer du JSON.

Mon fichier décodé est corrompu. En général pour l'une de ces trois raisons : la chaîne a été tronquée en route, du Base64URL a été décodé comme du Base64 standard, ou les espaces et sauts de ligne n'ont pas été retirés au préalable.

Pour aller plus loin

• Encoder un texte ou un fichier : encodeur Base64
• Lire une chaîne encodée : décodeur Base64
• Inspecter un jeton : décodeur JWT