Qu'est-ce que l'encodage Base64 ?
L’encodage Base64 transforme n’importe quelle donnée, texte ou binaire, en une chaîne composée de seulement 64 caractères ASCII imprimables, pour qu’elle traverse sans dommage les systèmes qui ne savent gérer que du texte. Ce n’est ni un chiffrement ni une compression : c’est une conversion réversible par n’importe qui, et le résultat est plus volumineux que l’original, pas plus petit.
Ce que fait réellement l’encodage Base64
L’alphabet Base64 tient en 64 symboles : les lettres A-Z, les lettres a-z, les chiffres 0-9, plus les deux caractères + et /. Un caractère supplémentaire, le signe =, sert uniquement de padding (on y revient plus bas). Chaque groupe de 3 octets de données d’entrée devient exactement 4 caractères Base64 en sortie, ce qui explique pourquoi le résultat encodé pèse environ 33 % de plus que l’original.
C’est le point que presque tout le monde confond au moins une fois : Base64 n’est pas une mesure de sécurité. Il n’y a aucune clé, aucun secret, et n’importe qui peut décoder la chaîne en une fraction de seconde avec n’importe quel outil, y compris celui plus bas sur cette page. Mettre un mot de passe en Base64 et croire qu’on vient de le protéger est une erreur de sécurité concrète, pas un détail théorique : c’est exactement comme écrire ce mot de passe à l’envers et penser que personne ne saura le relire.
Comment ça marche : encoder “Man” bit par bit
Le mot “Man” est un exemple classique pour comprendre le mécanisme, parce que ses 3 lettres tombent pile sur un groupe de 3 octets, sans padding pour brouiller la démonstration. Chaque lettre a sa valeur ASCII : M vaut 77, a vaut 97, n vaut 110. En binaire sur 8 bits chacune, cela donne 01001101, 01100001 et 01101110.
Mis bout à bout, ces trois octets forment une seule chaîne de 24 bits : 010011010110000101101110. Base64 ne relit pas ces bits par groupes de 8 (les octets d’origine), mais par groupes de 6, ce qui donne quatre paquets au lieu de trois :
| Groupe de 6 bits | Valeur décimale | Caractère Base64 |
|---|---|---|
| 010011 | 19 | T |
| 010110 | 22 | W |
| 000101 | 5 | F |
| 101110 | 46 | u |
Résultat : “Man” devient “TWFu”. Il n’y a rien de magique là-dedans, c’est un changement de base : on regroupe les mêmes bits différemment, par paquets de 6 au lieu de 8, et chaque valeur entre 0 et 63 pointe vers un des 64 caractères de l’alphabet.
Le padding : pourquoi certaines chaînes Base64 se terminent par =
Le découpage en groupes de 6 bits ne tombe juste que lorsque le nombre d’octets d’entrée est un multiple de 3. Dans les autres cas, le dernier groupe est incomplet et Base64 le complète avec des zéros, puis ajoute un ou deux signes = pour indiquer combien de caractères de la fin sont du padding plutôt que de la donnée réelle.
| Entrée | Octets | Sortie Base64 | Explication |
|---|---|---|---|
| M | 1 octet | TQ== | 1 octet ne remplit pas un groupe de 3, donc 2 caractères de vraie donnée + 2 caractères de padding |
| Ma | 2 octets | TWE= | 2 octets donnent 3 caractères de vraie donnée + 1 caractère de padding |
| Man | 3 octets | TWFu | 3 octets remplissent le groupe exactement, 4 caractères, aucun padding |
C’est pour ça qu’un = ou un == en fin de chaîne n’est pas un caractère de donnée : c’est un marqueur de remplissage, et un décodeur strict s’en sert pour savoir où s’arrête la vraie information.
Où vous croiserez du Base64 en pratique
Le cas le plus courant est l’en-tête HTTP Basic Authentication. Quand un client envoie un identifiant et un mot de passe par cette méthode, il les concatène avec un deux-points, encode le résultat en Base64, et l’envoie tel quel : user:pass1234 devient dXNlcjpwYXNzMTIzNA==, et l’en-tête ressemble à Authorization: Basic dXNlcjpwYXNzMTIzNA==. Encore une fois, ce n’est pas du chiffrement : quiconque intercepte cet en-tête peut décoder l’identifiant et le mot de passe instantanément, d’où l’obligation de passer par HTTPS.
Un autre usage fréquent consiste à glisser un petit bloc JSON dans un paramètre d’URL ou une charge utile où seul du texte est accepté. Le JSON {"id":42,"active":true} devient eyJpZCI6NDIsImFjdGl2ZSI6dHJ1ZX0= une fois encodé, une chaîne sans guillemets ni accolades qui voyage sans risque dans une URL. Le texte anglais “Hello, World!” suit le même principe et donne SGVsbG8sIFdvcmxkIQ==.
Base64 apparaît aussi dans les data URLs en CSS et en HTML (une image encodée directement dans le code plutôt que chargée depuis un fichier séparé), dans les pièces jointes des e-mails au format MIME, et dans les jetons JWT. Un JWT est composé de trois segments Base64url séparés par des points : en-tête.charge utile.signature. Le décodeur Base64 plus bas sur cette page ne fait pas d’analyse JWT spécialisée, mais le segment central (la charge utile) est justement une chaîne Base64 ordinaire : coller ce segment dans un décodeur Base64/Base64url classique suffit à en lire le contenu.
Un piège fréquent avec du texte réel : Base64 encode des octets, pas des caractères visibles. Le mot “café” fait 4 lettres à l’œil, mais le é occupe 2 octets en UTF-8, ce qui porte le total à 5 octets et donne “Y2Fmw6k=” en sortie, 8 caractères Base64 et non les 6 qu’on attendrait naïvement en comptant les lettres. Un simple emoji comme 🚀 est encore plus frappant : il tient dans un seul caractère visible mais occupe 4 octets en UTF-8, ce qui donne “8J+agA==” une fois encodé.
Encodez ou décodez votre propre texte
Tapez ou collez un texte dans l’encodeur ci-dessous pour voir sa version Base64 en direct, puis utilisez le décodeur juste après pour faire le chemin inverse.
Erreurs courantes et cas particuliers
Confondre Base64 avec du chiffrement. Ça mérite d’être répété une seconde fois avec des mots simples : encoder une donnée sensible en Base64 ne la protège en rien. C’est une anti-pratique de sécurité, pas une simplification acceptable. Si la confidentialité compte, il faut du vrai chiffrement, avec une clé, pas un changement de format.
Coller du Base64 standard dans une URL sans y penser. Les caractères + et / de l’alphabet standard posent problème dans une URL ou un nom de fichier : le + peut être interprété comme un espace, et le / comme un séparateur de chemin. C’est pour cette raison qu’existe une variante appelée Base64URL, qui remplace + par - et / par _, et qui se passe souvent du padding en =. C’est ce qui explique pourquoi certaines chaînes qui ressemblent à du Base64 dans une URL ou un JWT n’ont ni +, ni /, ni =.
Espaces, sauts de ligne ou padding manquant. Un décodeur strict refuse une chaîne qui contient des espaces, des retours à la ligne insérés en plein milieu, ou à qui il manque son padding en =. Ces caractères parasites apparaissent parfois quand on copie du Base64 depuis un e-mail ou un fichier de configuration mal formaté.
Sous-estimer le texte multi-octets. Comme vu plus haut avec “café” et 🚀, tout caractère accentué, tout idéogramme CJK et tout emoji encode plus d’octets que ce que le nombre de caractères visibles laisse penser, parce que Base64 travaille sur des octets UTF-8, pas sur des caractères.
Encoder deux fois par erreur. Encoder en Base64 une chaîne déjà en Base64 produit un résultat qui ressemble encore à du Base64, mais qui ne redonne rien de lisible si on ne le décode qu’une seule fois. Si un décodage renvoie un charabia qui contient encore des lettres et des chiffres bien formés, essayez de décoder une seconde fois avant de conclure que la donnée est corrompue.
Questions fréquentes
Base64 chiffre-t-il mes données ? Non. C’est un encodage réversible sans clé secrète. N’importe qui peut décoder une chaîne Base64 avec un outil comme celui de cette page. Pour protéger une donnée, il faut un vrai chiffrement.
Pourquoi la sortie Base64 est-elle plus longue que le texte d’origine ? Parce que chaque groupe de 3 octets d’entrée devient 4 caractères de sortie. C’est mécanique : le résultat encodé pèse environ 33 % de plus que l’original, quel que soit le contenu.
Pourquoi certaines chaînes Base64 se terminent par un ou deux signes = ? Parce que le nombre d’octets d’entrée n’était pas un multiple de 3. Le signe = marque du padding ajouté pour compléter le dernier groupe, pas une donnée réelle. “TQ==” pour 1 octet et “TWE=” pour 2 octets en sont les exemples les plus simples.
Quelle différence entre Base64 et Base64URL ? Le même principe d’encodage, mais un alphabet légèrement différent : Base64URL remplace + par - et / par _, et omet souvent le padding en =, pour éviter tout conflit avec la syntaxe des URLs, des noms de fichiers ou des JWT.
Ce décodeur peut-il lire un jeton JWT complet ? Il décode n’importe quel segment Base64 ou Base64url, y compris la charge utile centrale d’un JWT (le deuxième des trois segments séparés par des points). Il ne fait pas d’analyse JWT dédiée, mais coller ce segment suffit à en lire le JSON.