Comment fonctionne Base64

Base64 convertit des données binaires en texte pour qu’elles puissent passer par des canaux qui ne traitent que des caractères. La RFC 4648 définit le mécanisme : chaque groupe de 3 octets — 24 bits — devient 4 caractères d’un alphabet de 64 symboles, avec un padding de = quand les octets ne se divisent pas de façon égale. La taille augmente d’environ un tiers, et c’est un encodage, pas du chiffrement.

100 % local

Dans les années 1980, les systèmes de messagerie transportaient du texte 7 bits et rien d’autre ; les en-têtes HTTP, les champs JSON, les URL et les fichiers de log sont, en pratique, des territoires réservés au texte. Le binaire brut — une image, une signature, une clé cryptographique — se corrompt dès qu’un tel canal le rencontre. Base64 est le pont standard : une façon entièrement réversible d’écrire des octets arbitraires avec 64 caractères imprimables et sûrs, rien de plus.

Vous lisez du Base64 toute la journée sans le remarquer : chaque JWT comporte trois segments Base64url, chaque data: URI intégrée au CSS, chaque pièce jointe MIME d’un e-mail. Le schéma est spécifié dans la RFC 4648 — qui a réuni les définitions Base-64 antérieures en un seul document — et il est assez simple pour être calculé à la main. Ce guide fait exactement cela, un groupe de 24 bits à la fois.

Trois choses déroutent tout le monde au début : pourquoi 3 octets deviennent 4 caractères, à quoi servent les signes =, et pourquoi il existe deux alphabets. Chacune a sa section ci-dessous, avec les limites honnêtes — la pénalité de taille, les désaccords sur les espaces entre décodeurs, et l’erreur tenace qui consiste à prendre un encodage réversible pour de la sécurité.

Mieux vaut voir que décrire ici — collez n’importe quelle chaîne dans le décodeur Base64 et regardez les octets qu’elle cache ; le décodage se fait localement, donc jetons et clés restent dans votre onglet.

Le consommateur de Base64 le plus célèbre est le format de jeton ; le le guide de la structure JWT montre comment les trois segments d’un JWT s’appuient sur l’alphabet URL-safe défini ci-dessous.

Le mécanisme : 3 octets en entrée, 4 caractères en sortie

Prenez des données binaires quelconques et découpez-les en groupes de 3 octets — 24 bits. Scindez chaque groupe en quatre blocs de 6 bits. Chaque bloc est un nombre de 0 à 63, et l’alphabet de la RFC 4648 fait correspondre ces nombres à des caractères : A–Z pour 0–25, a–z pour 26–51, 0–9 pour 52–61, puis + et / pour 62 et 63. Six bits, c’est le point d’équilibre, car 2⁶ = 64 correspond exactement à la taille d’un alphabet que tout canal limité aux caractères peut transporter sans broncher.

L’exemple classique est le vecteur de test de la RFC elle-même, le mot Man — trois octets, aucun padding nécessaire :

Octet par octet

M   0x4D   01001101
a   0x61   01100001
n   0x6E   01101110

joined:    010011 010110 000101 101110
indexes:      19     22      5      46

Caractère par caractère

19→T   22→W   5→F   46→u

"Man"  →  TWFu
"Ma"   →  TWE=
"M"    →  TQ==

Le padding : ce que signifient les signes =

Des blocs de 6 bits ne se recomposent en octets que par groupes complets de quatre. Quand la longueur d’entrée n’est pas un multiple de 3, le dernier groupe reste court : 2 octets restants produisent trois caractères plus un signe =, et 1 octet restant produit deux caractères plus ==. Le padding rétablit la longueur pour que le décodeur calcule le nombre exact d’octets sans deviner — et = est le seul caractère extérieur à l’alphabet de 64 symboles qui puisse apparaître dans la sortie.

Le padding est une métadonnée de longueur, ni de la sécurité ni de la compression. La RFC 4648 autorise les variantes sans padding quand les deux parties sont d’accord — le Base64url des JWT se passe notamment de tout =, car les points délimitent les segments et la longueur de chaque segment en dit assez au décodeur.

Octets en entrée	Caractères en sortie	Padding	Exemple
3 (tout multiple de 3)	4 pour 3 octets	aucun	"Man" → TWFu
2	3	un =	"Ma" → TWE=
1	2	deux ==	"M" → TQ==
12	16	aucun	"Hello, world" → SGVsbG8sIHdvcmxk

Les deux alphabets : standard et URL-safe

L’alphabet standard utilise + et / — inoffensifs dans un e-mail, hostiles dans les URL, où + se décode comme un espace et / comme séparateur de chemin. La RFC 4648 §5 définit donc Base64url, qui remplace + par - et / par _ : des caractères qui n’exigent ni encodage pourcentage dans les URL, ni guillemets dans les noms de fichiers ou les cookies. À cela près, les deux dialectes sont identiques — mêmes blocs de 6 bits, mêmes règles de padding.

Voilà le piège concret : les dialectes ne diffèrent que de deux caractères, si bien qu’un jeton collé avec le mauvais alphabet échoue dès le deuxième caractère — ou pire, se décode en octets différents s’il contient par hasard + ou /. Les décodeurs bien conçus acceptent les deux formes et vous disent laquelle ils ont vue ; les stricts refusent carrément les alphabets mélangés plutôt que de deviner.

Valeurs	Standard	URL-safe
0–25	A–Z	A–Z
26–51	a–z	a–z
52–61	0–9	0–9
62	+	-
63	/	_

Mêmes octets, deux dialectes

bytes:    0xFB 0xEF 0xBE

standard:  ++++
url-safe:  ----

Là où les dialectes mordent

dans une query d’URL, ++++ arrive sous forme de quatre espaces
(règle du plus converti en espace) — ---- arrive intact.
C’est pourquoi les jetons utilisent l’alphabet compatible URL.

Taille : la taxe d’un tiers et ses petites lignes

Quatre caractères portent trois octets, donc la sortie encodée vaut toujours 4/3 de l’entrée — soit environ 33% de plus — avant toute surcharge de transport. Pour fixer les idées : 100 octets s’encodent en 136 caractères, 17 octets en 24, et ce rapport ne bouge jamais, car c’est de l’arithmétique, pas du réglage. Le padding, les sauts de ligne et le repliement ajoutent encore : MIME plafonne les lignes Base64 à 76 caractères et impose des sauts CRLF entre elles, ce qui ajoute un peu de volume sur les grosses charges. Une data: URI embarque cette forme déjà gonflée dans du CSS ou du HTML — voilà pourquoi les images intégrées pèsent environ un tiers de plus que les fichiers binaires qu’elles remplacent.

Aucune transformation réversible ne réduit la taille des données, et Base64 ne fait pas exception — c’est un changement d’écriture, pas de la compression. Si la taille compte, compressez d’abord puis encodez les octets compressés ; jamais l’inverse.

Espaces, sauts de ligne et désaccords entre décodeurs

La RFC 4648 est stricte : les décodeurs doivent rejeter tout caractère hors alphabet, et le document lui-même n’exige aucun saut de ligne. Le Base64 de MIME (RFC 2045) attend l’inverse — un CRLF toutes les 76 caractères. Les implémentations réelles se répartissent entre les deux pôles : beaucoup suppriment silencieusement les espaces, d’autres les exigent, d’autres encore rejettent tout retour à la ligne. C’est la raison classique pour laquelle une chaîne qui « s’encode bien » dans un outil refuse de se décoder dans un autre.

La règle d’interopérabilité honnête : produire du Base64 standard, avec padding et sans repliement, sauf si une spécification impose autre chose, et construire des décodeurs qui tolèrent les espaces ajoutés par d’autres outils — tout en refusant tout caractère qui ne fait partie d’un alphabet reconnu, car c’est par cette tolérance-là que commence la corruption silencieuse des octets.

Ce que Base64 n’est pas

Base64 n’a ni clé, ni rondes de mélange, ni secret : n’importe qui peut l’inverser, et des décodeurs sont livrés dans la bibliothèque standard de chaque langage. Prendre une charge encodée pour des données protégées revient régulièrement dans les rapports de vulnérabilités. Les signes révélateurs sont publics : SGVsbG8= écrit Hello, JVBERi0x ouvre un PDF, /9j/ commence un JPEG, et eyJ débute presque chaque JSON Web Token — ces premiers caractères sont simplement le Base64 de %PDF-, des octets magiques du JPEG et d’une accolade ouvrante JSON.

Utilisez Base64 pour ce qu’il est : une écriture des octets qui passe dans tous les conteneurs. Confiez la confidentialité à un vrai chiffrement — TLS en transit, un chiffrement solide au repos — et gardez Base64 comme dernière étape qui rend le résultat imprimable, rien de plus.

Des débuts révélateurs

SGVsbG8sIHdvcmxk
JVBERi0xLjQ=
/9j/
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Ce qu'ils donnent en clair

Hello, world
%PDF-1.4
(octets FF D8 FF : le nombre magique d’un JPEG)
{"alg":"HS256","typ":"JWT"}

Questions fréquentes

Est-il sûr de coller des jetons et des clés dans un décodeur Base64 ?

Sur ce site, oui : le décodeur s’exécute dans votre navigateur et ne transmet jamais votre saisie — il n’existe aucun point d’envoi par où fuiter. Le panneau Network n’affiche aucune requête pendant que vous décodez, et la Content-Security-Policy du site bloque les connexions sortantes. Ce n’est pas un détail : les jetons Base64 sont des identifiants actifs, et bien des décodeurs web pris au hasard se montrent bien moins soigneux quant à ce qu’ils en font.

Base64 est-il du chiffrement ?

Non — c’est un encodage, sans clé et sans propriété de secret. N’importe quelle bibliothèque, et n’importe quel humain attentif, peut l’inverser instantanément ; un mot de passe encodé est un mot de passe visible. Le chiffrement transforme les données pour qu’elles soient illisibles sans clé, tandis que Base64 se contente de réécrire les octets pour que des canaux limités au texte puissent les transporter. Les deux résolvent des problèmes différents et apparaissent souvent ensemble.

Pourquoi la sortie Base64 se termine-t-elle par des signes = ?

Le = est du padding qui rétablit la longueur. La sortie vient par groupes de 4 caractères, et quand l’entrée n’était pas un multiple de 3 octets, le dernier groupe est complété — un = pour deux octets restants, deux pour un seul, jamais trois, car un groupe complet n’en demande aucun. Ces signes ne portent aucune donnée ; ils indiquent au décodeur le nombre exact d’octets.

Quelle différence entre Base64 et Base64url ?

Deux caractères. Base64url, défini dans la RFC 4648 §5, remplace + par - et / par _, si bien que la sortie est sans danger dans les URL, les noms de fichiers et les cookies, sans échappement. Tout le reste — le découpage en blocs de 6 bits, les lettres et les chiffres, les règles de padding — est identique, et des formats comme les JWT utilisent la variante URL-safe sans padding.

Pourquoi la sortie Base64 est-elle plus grande que son entrée ?

Chaque caractère de sortie porte 6 bits quand un octet en porte 8, donc 3 octets — 24 bits — exigent 4 caractères : un facteur fixe de 4/3, soit environ 33% de surcoût, avant même le padding et les sauts de ligne. C’est le prix du caractère imprimable ; aucun encodage réversible ne l’évite, et c’est pourquoi le transport binaire brut gagne partout où le canal accepte de vrais octets.

Peut-on décoder du Base64 à la main ?

Oui — la conception y invite. Écrivez les octets de l’entrée en binaire, regroupez chaque bloc de 24 bits en quatre blocs de 6 bits, et lisez chaque bloc dans la table de l’alphabet : A=0 jusqu’à Z=25, a=26 jusqu’à z=51, 0=52 jusqu’à 9=61, puis + et /. L’exemple de la RFC se fait sur papier : Man donne 010011 010110 000101 101110, soit T, W, F, u — TWFu.

Où puis-je lire les normes citées ici ?

RFC 4648 — Les encodages de données Base16, Base32 et Base64
RFC 2045 — MIME, première partie : format des corps de message Internet

Équipe ToolsByUs · Comment nous vérifions nos outils