Base64 expliqué : pourquoi, quand et les variantes courantes

Base64 est partout — pièces jointes d’e-mail, tokens JWT, URI de données, blocs PEM de certificats, secrets clients OAuth, charges utiles de notifications push — et presque personne ne s’arrête pour demander ce qu’il fait réellement. Il accomplit un travail spécifique, a trois variantes presque identiques, et les différences entre elles causent la plupart des bugs.

Quel problème Base64 résout

De nombreux canaux de transport sont conçus pour le texte, pas les octets arbitraires. Les corps d’e-mail devaient historiquement être en ASCII imprimable. Les URL ne peuvent pas contenir de caractères de contrôle bruts ou d’espaces. Les chaînes JSON doivent être en Unicode valide. Si vous voulez envoyer un PNG dans l’un de ces canaux, les octets bruts casseront le canal.

Base64 prend n’importe quelle séquence d’octets et la réexprime en utilisant seulement 64 caractères sûrs plus un rembourrage optionnel. Le résultat va partout où va le texte, et un décodeur récupère les octets originaux exactement. Il n’y a pas de perte, pas de compression, et pas de sécurité — juste un changement de format.

L’alphabet

Base64 standard (RFC 4648 §4) utilise 65 caractères en tout :

• A–Z — valeurs 0–25
• a–z — valeurs 26–51
• 0–9 — valeurs 52–61
• + — valeur 62
• / — valeur 63
• = — rembourrage, pas de valeur

Chaque caractère porte 6 bits (car 2⁶ = 64). Trois octets d’entrée (24 bits) se mappent à quatre caractères de sortie (24 bits). Quand l’entrée n’est pas un multiple de 3 octets, l’encodeur rembourre avec des zéros à droite et émet = pour chaque étape de rembourrage.

Pourquoi la sortie est 33 % plus grande

4 caractères de sortie ne portent que ce que 3 octets d’entrée portaient, donc l’inflation est exactement 4/3 = 1,333…, soit 33,3 % de plus. Le rembourrage ajoute un tout petit peu plus pour les courtes entrées. Un fichier binaire de 1 Mo devient une chaîne Base64 de 1,33 Mo. C’est le prix du transport sûr en texte.

Essayez notre encodeur / décodeur Base64 avec un exemple d’entrée — vous verrez le ratio de taille indiqué à côté du résultat.

Les trois variantes que vous rencontrerez

Base64 standard (RFC 4648 §4)

L’original. L’alphabet inclut + et /, rembourrage avec =requis. Utilisé par les fichiers PEM (certificats TLS, clés SSH), XML Signature, les pièces jointes SOAP et l’en-tête HTTP Authorization: Basic.

Base64url (RFC 4648 §5)

Sûr pour les URL et noms de fichiers. Remplace + par - et / par _. Le rembourrage est techniquement optionnel dans la spec mais presque toujours omis en pratique. C’est ce que JWT, JWS, JWE, OAuth PKCE, WebPush VAPID et WebAuthn utilisent. Les deux caractères qui diffèrent sont ceux qui nécessitaient auparavant un encodage pourcent dans les URL.

Base64 standard et URL-safe ne sont pas directement interchangeables. Un décodeur qui connaît un alphabet rejettera l’entrée dans l’autre. Voir notre comparaison Base64 vs Base64url pour les règles exactes.

MIME Base64 (RFC 2045)

La variante originale des pièces jointes d’e-mail. Même alphabet que Base64 standard, mais avec un saut de ligne dur (\r\n) inséré toutes les 76 caractères car les anciens relais SMTP se bloquaient sur les longues lignes. Les espaces blancs dans MIME Base64 doivent être ignorés par le décodeur. Si vous générez du Base64 pour un champ JSON ou un JWT, n’insérez jamais de sauts de ligne.

Où Base64 apparaît dans la nature

• Tokens JWT — trois sections base64url (sans rembourrage) jointes par des points. En-tête. Charge utile. Signature.
• Auth HTTP Basic — username:passwordencodé en Base64 standard, envoyé dans l’en-tête Authorization. (Pourquoi “Basic” n’est pas un mécanisme de sécurité sans TLS.)
• URI de données — data:image/png;base64,iVBORw0KG… intègre le binaire directement en HTML ou CSS. La partie image/png est un type MIME — sans lui le navigateur doit détecter les octets et peut refuser de rendre.
• Fichiers PEM — certificats TLS, clés SSH, messages PGP. Base64 standard encapsulé dans des en-têtes -----BEGIN…----- / -----END…-----.
• Pièces jointes e-mail — MIME Base64 avec saut de ligne toutes les 76 caractères.
• Secrets Kubernetes — les ressources Secret Kubernetes sont des valeurs encodées en Base64 standard (ce qui confond fameux les gens qui pensent qu’elles sont chiffrées).

Pièges courants

Encoder des chaînes sans préciser UTF-8

Base64 ne connaît pas les caractères — il encode des octets. Si vous encodez en Base64 la chaîne “café”, le résultat dépend entièrement de l’encodage d’octets choisi (UTF-8 donne 5 octets produisant Y2Fmw6k= ; Latin-1 donne 4 octets produisant Y2Fm6Q==). Décoder sous une hypothèse différente donne des données corrompues. La convention moderne est UTF-8 pour toute entrée texte.

Mélanger standard et URL-safe

Une chaîne contenant - ou _ est en base64url ; les décodeurs Base64 standard la rejettent. Une chaîne contenant + ou /est en standard ; les décodeurs URL-safe la rejettent. Si vous contrôlez les deux extrémités, choisissez une variante et documentez-la. Sinon, normalisez sur l’entrée par substitution de classe de caractères avant le décodage.

Désalignement de rembourrage

Les JWT et formats similaires suppriment le rembourrage. Les décodeurs naïfs l’exigent et lèvent InvalidBase64. La solution est de réajouter des caractères =jusqu’à ce que la longueur d’entrée soit un multiple de 4 — généralement un ou deux.

Traiter Base64 comme une frontière de sécurité

Les Secrets Kubernetes sont en Base64, pas chiffrés. Encoder en Base64 un mot de passe dans le code client ne le protège pas. Base64 ne cache rien à quiconque possède un décodeur — et chaque ordinateur en a un.

Gonflement des URI de données

Intégrer une image de 200 Ko en Base64 la fait grossir à 266 Ko et bloque le thread principal pendant que le navigateur analyse l’URI. Pour tout ce qui dépasse quelques Ko, servez le fichier depuis une URL normale et laissez le navigateur le mettre en cache.

Essayez l’encodeur

Collez du texte ou téléchargez un fichier dans notre encodeur / décodeur Base64. Il supporte les deux alphabets standard et URL-safe, affiche explicitement le comportement de rembourrage, et indique les tailles d’entrée/sortie en octets pour que vous puissiez voir l’inflation pour votre entrée spécifique. L’entrée du glossaire Base64 est la version en un paragraphe.

Conclusion

Base64 est un outil de transport pratique, pas une fonctionnalité de sécurité. Il vous coûte un tiers de vos octets et vous le rend en compatibilité avec les canaux texte uniquement. Les variantes comptent — standard pour PEM et HTTP Basic, URL-safe pour les JWT et OAuth, MIME pour les e-mails — et elles ne se décodent pas mutuellement sans transcodage. Soyez toujours explicite sur la variante que vous produisez et consommez, et encodez toujours les chaînes Unicode en octets UTF-8 d’abord.