Qu'est-ce que l'encodage Base64 et pourquoi s'appelle-t-il « Base64 » ?

Base64 est un schéma d'encodage binaire vers texte qui représente des données binaires en utilisant 64 caractères ASCII imprimables : A-Z (26), a-z (26), 0-9 (10), plus '+' et '/' (2), soit 64 au total. Le caractère '=' est utilisé pour le rembourrage. Il s'appelle Base64 parce qu'il y a 64 valeurs possibles pour chaque caractère encodé, et chaque caractère encode exactement 6 bits des données originales (2^6 = 64).

L'encodage Base64 chiffre-t-il mes données ?

Non. Base64 est un schéma d'encodage, pas un algorithme de chiffrement. L'encodage est réversible sans aucune clé — quiconque possède une chaîne Base64 peut la décoder instantanément avec n'importe quel décodeur Base64. Si vous devez protéger des données contre un accès non autorisé, vous devez utiliser le chiffrement (comme AES-256) avant ou à la place de l'encodage. Base64 ne sert qu'à rendre les données binaires sûres pour la transmission dans des protocoles textuels — il ne fournit aucune confidentialité.

Quelle est la taille de la sortie Base64 par rapport aux données originales ?

L'encodage Base64 augmente la taille des données d'environ 33 %. Chaque groupe de 3 octets d'entrée devient 4 caractères Base64, et des caractères de rembourrage ('=') sont ajoutés pour que la longueur de sortie soit un multiple de 4. Par exemple, 3 octets deviennent 4 caractères, 6 octets deviennent 8 caractères, et 1 Mo devient environ 1,37 Mo après encodage. Ce surcoût est le principal compromis lors du choix d'utiliser Base64.

Quelle est la différence entre Base64 standard et Base64 URL-safe ?

Le Base64 standard utilise '+' et '/' comme 62e et 63e caractères. Ces caractères ont des significations spéciales dans les URLs : '+' est décodé comme un espace dans les chaînes de requête, et '/' est un séparateur de chemin. Le Base64 URL-safe (aussi appelé Base64url) remplace '+' par '-' et '/' par '_', rendant la chaîne encodée sûre à inclure dans les URLs et les noms de fichiers sans encodage en pourcentage supplémentaire. Les caractères de rembourrage ('=') sont souvent omis dans l'encodage URL-safe. Les jetons JWT, par exemple, utilisent Base64url sans rembourrage.

Dois-je utiliser Base64 pour stocker des mots de passe ?

Absolument pas. Base64 est trivialement réversible — n'importe quelle chaîne Base64 peut être décodée vers sa valeur originale en quelques millisecondes. Stocker des mots de passe encodés en Base64 équivaut à les stocker en texte clair. Les mots de passe doivent être hachés avec une fonction de hachage appropriée comme bcrypt, scrypt ou Argon2, conçues pour être computationnellement coûteuses et irréversibles. Base64 n'a aucun rôle dans le stockage des mots de passe.

Quand ne dois-je PAS utiliser l'encodage Base64 ?

Évitez Base64 quand : (1) Vous avez besoin de sécurité — Base64 n'est pas du chiffrement. (2) Vous intégrez des fichiers volumineux comme des images dans HTML/CSS — le surcoût de 33 % et l'impossibilité de mettre en cache la ressource séparément nuisent aux performances. (3) Vous stockez de grandes données binaires dans une base de données — stockez le binaire dans une colonne binaire dédiée ou dans un stockage d'objets comme S3, pas en chaînes Base64. (4) Vous avez besoin d'un traitement rapide — l'encodage et le décodage Base64 ajoutent une charge CPU pour les grandes charges utiles. Utilisez Base64 uniquement lorsque vous devez véritablement représenter des données binaires sous forme de texte ASCII dans un protocole ou format ne pouvant pas gérer le binaire brut.

Comprendre l'encodage Base64 — Guide complet pour développeurs

10 mai 2026 Toova

L'encodage Base64 apparaît dans presque tous les domaines du développement web — jetons JWT, URI de données, pièces jointes d'e-mail, charges utiles d'API, signatures cryptographiques et fichiers de configuration. Malgré son omniprésence, il est souvent mal compris : les développeurs le confondent parfois avec le chiffrement, ou l'utilisent dans des situations où il aggrave les choses. Ce guide explique exactement comment fonctionne Base64, quand l'utiliser, quand l'éviter, et comment l'utiliser correctement en JavaScript.

Ce qu'est (et n'est pas) l'encodage Base64

Base64 est un schéma d'encodage binaire vers texte. Son seul rôle est de convertir des données binaires arbitraires en une chaîne de caractères ASCII imprimables. Il ne compresse pas les données, ne les chiffre pas et ne les valide pas. C'est uniquement une transformation de représentation — prendre des octets qui pourraient inclure des octets nuls, des caractères de contrôle ou des valeurs qui briseraient les protocoles textuels, et les convertir vers un jeu de caractères sûr.

Le nom vient des 64 caractères imprimables utilisés comme alphabet d'encodage : A–Z (26 caractères), a–z (26 caractères), 0–9 (10 caractères), plus + et / (2 caractères). Le caractère = est utilisé pour le rembourrage. Puisqu'il y a 64 valeurs possibles par position de caractère et 2^6 = 64, chaque caractère Base64 encode exactement 6 bits des données originales.

Comment fonctionne Base64 — « Hello » étape par étape

La meilleure façon de comprendre Base64 est de suivre un exemple concret. Encodons la chaîne Hello.

Étape 1 : Convertir en octets

Chaque caractère de Hello correspond à son code ASCII, exprimé en binaire (8 bits par octet) :

H  e  l  l  o
72 65 6C 6C 6F   (ASCII / hex)
01001000 01100101 01101100 01101100 01101111   (binaire)

Étape 2 : Regrouper en morceaux de 6 bits

Concatenez tous les bits : 0100100001100101011011000110110001101111 (40 bits). Base64 traite 3 octets (24 bits) à la fois et les associe à 4 caractères Base64 (4 × 6 = 24 bits). Regroupez les 40 bits en morceaux de 6 bits, en complétant le dernier groupe avec des zéros :

010010 000110 010101 101100 011011 000110 1111
18     6      21     44     27     6      (dernier groupe complété à 6 bits : 111100 = 60)

Étape 3 : Associer à l'alphabet Base64

Chaque valeur de 6 bits correspond à un caractère de l'alphabet Base64 (A=0, B=1, ... Z=25, a=26, ... z=51, 0=52, ... 9=61, +=62, /=63). Puisque 5 octets n'est pas un multiple de 3, un caractère de rembourrage = est ajouté :

Index : 18  6   21  44  27  6   60
Char :  S   G   V   s   b   G   8
Résultat : SGVsbG8=   (= est le rembourrage)

Résultat

"Hello" → "SGVsbG8="

Vous pouvez vérifier cela instantanément avec l'encodeur/décodeur Base64 Toova — collez Hello, cliquez sur Encoder, et vous obtenez SGVsbG8=. Cliquez sur Décoder pour inverser.

Le surcoût de 33 %

L'encodage Base64 augmente toujours la taille des données d'environ 33 %. Le calcul est simple : 3 octets d'entrée (24 bits) produisent 4 caractères Base64 (24 bits encodés en 4 groupes de 6 bits). C'est un ratio de 4/3, soit 33,3 % de surcoût. En ajoutant les caractères de rembourrage, le surcoût réel est compris entre 33 % et 36 %, selon la longueur de l'entrée.

Cela compte significativement pour les performances. Une image de 1 Mo intégrée comme data URI Base64 dans du HTML devient environ 1,37 Mo. Une API qui encode toutes les charges utiles binaires en Base64 envoie 33 % de données de plus que nécessaire. Pour les petites valeurs comme les jetons courts ou les sommes de contrôle, le surcoût est négligeable. Pour les fichiers volumineux, c'est un coût réel.

La variante URL-safe

Le Base64 standard utilise + et / comme les deux derniers caractères de l'alphabet. Ces deux caractères sont problématiques dans les URLs :

+ est décodé comme un espace dans les chaînes de requête
/ est un séparateur de chemin dans les URLs

Le Base64 URL-safe (aussi appelé Base64url, défini dans la Section 5 de la RFC 4648) remplace + par - et / par _. Le rembourrage (=) est généralement omis dans les contextes URL-safe car il peut aussi être mal interprété par certains analyseurs d'URL.

Les jetons JWT utilisent Base64url sans rembourrage. Lorsque vous décodez manuellement un en-tête ou une charge utile JWT, vous devez gérer à la fois la substitution de caractères et le rembourrage manquant. Voici comment le faire en JavaScript :

// Base64 URL-safe (remplacer + par - et / par _)
function toBase64Url(base64) {
  return base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');
}

function fromBase64Url(base64url) {
  const padded = base64url.padEnd(
    base64url.length + (4 - base64url.length % 4) % 4,
    '='
  );
  return atob(padded.replace(/-/g, '+').replace(/_/g, '/'));
}

L'encodeur/décodeur Base64 Toova prend en charge les variantes standard et URL-safe avec un simple bouton bascule.

Base64 en JavaScript

Navigateur : btoa() et atob()

Les navigateurs proposent deux fonctions intégrées : btoa() (binary to ASCII, c'est-à-dire encoder) et atob() (ASCII to binary, c'est-à-dire décoder). Malgré l'ordre confus des noms, elles sont disponibles dans les navigateurs depuis plus d'une décennie.

// Navigateur — atob / btoa (chaînes uniquement, ASCII-safe)
const encoded = btoa("Hello");
console.log(encoded); // "SGVsbG8="

const decoded = atob("SGVsbG8=");
console.log(decoded); // "Hello"

Limitation importante : btoa() n'accepte que les chaînes avec des caractères dans la plage Latin-1 (points de code 0–255). Si vous passez une chaîne contenant des caractères Unicode comme des emojis ou des caractères CJK, elle lève une DOMException. Pour encoder des données binaires arbitraires, convertissez-les d'abord en Uint8Array :

// Navigateur — encodage de données binaires arbitraires (Uint8Array)
const bytes = new Uint8Array([72, 101, 108, 108, 111]);
const encoded = btoa(String.fromCharCode(...bytes));
console.log(encoded); // "SGVsbG8="

Pour encoder des chaînes arbitraires pouvant contenir des caractères Unicode, l'approche moderne recommandée est d'utiliser TextEncoder pour obtenir un Uint8Array d'abord, puis d'encoder comme indiqué ci-dessus.

Node.js : Buffer

Node.js fournit la classe Buffer, qui gère correctement les données binaires et prend en charge plusieurs encodages dont Base64 et Base64url :

// Node.js — Buffer (gère correctement le binaire)
const encoded = Buffer.from('Hello').toString('base64');
console.log(encoded); // "SGVsbG8="

const decoded = Buffer.from('SGVsbG8=', 'base64').toString('utf8');
console.log(decoded); // "Hello"

// Variante URL-safe dans Node.js
const urlSafe = Buffer.from('Hello').toString('base64url');
console.log(urlSafe); // "SGVsbG8" (sans rembourrage)

L'option d'encodage base64url (disponible depuis Node.js 16) gère automatiquement la substitution de caractères et la suppression du rembourrage, ce qui est beaucoup plus simple que d'effectuer la transformation manuellement.

Pour les environnements navigateur qui doivent gérer de grands fichiers binaires, la méthode FileReader.readAsDataURL encode le fichier comme data URI Base64 sans charger tout en mémoire d'un coup.

Quand utiliser Base64

Intégrer des données binaires dans des protocoles uniquement textuels

Le cas d'usage originel de Base64 était l'encodage des pièces jointes d'e-mails binaires dans SMTP, un protocole qui ne prend en charge que le texte ASCII 7 bits. Le même principe s'applique partout où vous devez inclure des données binaires dans un format ne pouvant pas gérer les octets bruts : charges utiles d'API JSON, documents XML, attributs HTML, valeurs CSS, en-têtes HTTP.

Data URIs pour les petits assets

CSS et HTML vous permettent d'intégrer des images, des polices et des SVGs comme data URIs Base64. Cela élimine un aller-retour HTTP pour les petits assets comme les icônes et évite le flash de contenu non stylisé pour les images critiques au-dessus de la ligne de flottaison.

<!-- Icône SVG intégrée comme data URI Base64 -->
<img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0c..." alt="icône" />

<!-- Arrière-plan CSS intégré -->
.icon {
  background-image: url("data:image/png;base64,iVBORw0KGgo...");
}

Le compromis : les data URIs Base64 ne peuvent pas être mis en cache séparément du fichier HTML/CSS qui les contient. Si l'image ne change jamais mais que le HTML environnant change, le navigateur re-télécharge les données de l'image à chaque rechargement de page. Utilisez les data URIs uniquement pour les petits assets (idéalement moins de 4 Ko) où l'élimination d'un aller-retour compense la pénalité de cache.

Encodage de données binaires pour JSON ou paramètres URL

JSON est un format texte — il ne peut pas représenter directement les octets binaires bruts. Lorsqu'une API doit transmettre des données binaires (miniatures d'images, signatures cryptographiques, données compressées), Base64 est la façon standard de les inclure dans une charge utile JSON. De même, si vous devez passer des données binaires dans un paramètre de requête URL, l'encodage Base64url garantit que les données survivent à l'encodage en pourcentage sans corruption.

JWT et autres formats de jetons

Les jetons JWT utilisent Base64url pour encoder leurs sections d'en-tête et de charge utile. Cela fait du jeton une chaîne imprimable et URL-safe pouvant être passée dans des en-têtes HTTP, des cookies ou des paramètres URL. L'encodage n'est pas pour la sécurité (la charge utile est lisible par quiconque possède le jeton) — c'est uniquement pour une transmission sûre.

Quand ne PAS utiliser Base64

Sécurité ou confidentialité

Base64 ne fournit aucune sécurité. Il est trivialement réversible en quelques millisecondes. Ne l'utilisez pas pour « obscurcir » des mots de passe, des clés API ou des valeurs de configuration sensibles. Tout développeur qui voit une chaîne Base64 la décodera immédiatement. Si vous avez besoin de confidentialité, utilisez le chiffrement.

Stockage de mots de passe

Stocker des mots de passe encodés en Base64 revient à les stocker en texte clair — l'encodage est instantanément réversible. Les mots de passe doivent être hachés avec une fonction de hachage appropriée comme bcrypt, Argon2 ou scrypt.

Grands fichiers binaires

Encoder un fichier de 10 Mo en Base64 produit une chaîne de 13,7 Mo. Si vous la stockez dans une colonne de base de données, la parcourez ou la transmettez via une API, vous payez le surcoût de 33 % à chaque fois. Pour les grandes données binaires, utilisez un stockage binaire dédié : colonnes BLOB/BYTEA en base de données, stockage d'objets comme S3 ou GCS, ou streamer le binaire directement.

Situations où vous pouvez utiliser le binaire directement

Si votre protocole ou format prend en charge le binaire brut — par exemple, un WebSocket avec type de message binaire, un envoi HTTP multipart/form-data, ou un format de fichier binaire — utilisez le binaire directement. Base64 n'est nécessaire que lorsque le support de transport ne peut véritablement pas gérer les octets bruts.

Pièges courants

Confondre l'encodage avec le chiffrement

C'est l'erreur la plus courante. Base64 est visible. Ce n'est pas un mécanisme de sécurité. Des commentaires de code comme « le mot de passe est stocké encodé en Base64 pour la sécurité » indiquent un sérieux malentendu qui devrait être détecté lors de la revue de code.

Utiliser btoa() avec des chaînes Unicode

Appeler btoa() sur une chaîne contenant des caractères avec des points de code supérieurs à 255 lève une DOMException: Failed to execute 'btoa': The string to be encoded contains characters outside of the Latin1 range. Convertissez toujours en Uint8Array via TextEncoder avant d'encoder des chaînes pouvant contenir des caractères Unicode.

Oublier le rembourrage lors du décodage

Les chaînes Base64 doivent avoir des longueurs qui sont des multiples de 4. Si une chaîne Base64 a été générée sans rembourrage (courant dans l'encodage URL-safe), vous devez ajouter le nombre correct de caractères = avant le décodage. Une chaîne Base64 de longueur n nécessite (4 - n % 4) % 4 caractères de rembourrage. L'oublier provoque des erreurs de décodage difficiles à diagnostiquer.

Double encodage

Une chaîne Base64 est elle-même du texte ASCII valide, donc btoa(btoa(data)) fonctionne sans erreur mais produit une sortie doublement encodée. Lors du passage de valeurs Base64 à travers plusieurs couches de sérialisation (JSON dans JSON, par exemple), il est facile d'encoder les mêmes données deux fois. Décodez toujours exactement le même nombre de fois que vous avez encodé.

Référence rapide : Base64 en pratique

Pour l'encodage et le décodage dans le navigateur sans écrire de code, l'encodeur/décodeur Base64 Toova s'exécute entièrement dans votre navigateur — sans aller-retour serveur. Il prend en charge les variantes standard et URL-safe, le téléversement de fichiers pour encoder des fichiers binaires, et les sorties texte et hexadécimale pour les données décodées.

Si vous travaillez avec du contenu encodé dans des URLs, l'encodeur/décodeur URL gère l'encodage en pourcentage séparément de Base64. Pour les entités HTML, le convertisseur d'entités HTML gère l'échappement de caractères dans les contextes HTML. Ce sont des schémas d'encodage distincts — chacun a un cas d'usage spécifique.

La référence canonique pour Base64 est la RFC 4648, qui définit le Base64 standard (Section 4), Base64url (Section 5) et Base32 (Sections 6–7). Pour les APIs navigateur btoa() et atob(), la documentation MDN pour btoa() couvre la compatibilité navigateur et la limitation Unicode en détail.

Résumé

L'encodage Base64 convertit des données binaires en ASCII imprimable en utilisant un alphabet de 64 caractères. Il augmente la taille des données de 33 %, est complètement réversible et ne fournit aucune sécurité. Utilisez-le lorsque vous devez intégrer des données binaires dans un format textuel — charges utiles JSON, data URIs HTML, jetons JWT, pièces jointes d'e-mail, paramètres URL. Évitez-le lorsque vous avez besoin de sécurité, lorsque le transport prend en charge le binaire directement, ou lorsque le surcoût de 33 % compte à grande échelle.

Comprendre ce qu'est Base64 — et ce qu'il n'est pas — prévient les erreurs les plus courantes : l'utiliser pour la sécurité, l'appliquer inutilement aux grands fichiers et le confondre avec d'autres schémas d'encodage comme l'encodage URL ou les entités HTML. Chaque schéma d'encodage résout un problème spécifique. Base64 en résout exactement un : rendre les données binaires sûres pour les canaux uniquement textuels.

Prêt à encoder ou décoder ? Essayez l'encodeur/décodeur Base64 Toova — collez du texte ou déposez un fichier, basculez entre standard et URL-safe, et copiez le résultat. Sans compte, sans serveur, sans limite.