image base64 convert data-uri

Convertisseur rapide d'image en Base64 : Optimisez vos ressources Web

Convertissez instantanément des images en URI de données Base64. Réduisez les requêtes HTTP et accélérez les performances de votre site Web.

Qu'est-ce que le Base64 ?

Le Base64 est un schéma d'encodage binaire vers texte qui représente des données binaires en utilisant seulement 64 caractères ASCII imprimables : les lettres majuscules A–Z, les lettres minuscules a–z, les chiffres 0–9 et les deux symboles + et /. Un caractère de remplissage = est ajouté à la fin lorsque la longueur de l'entrée n'est pas un multiple de trois octets.

Le nom « Base64 » vient directement de la taille de cet ensemble de caractères. Comme chaque caractère de l'ensemble peut être représenté avec exactement 6 bits (2⁶ = 64), le Base64 encode trois octets (24 bits) de données binaires en quatre caractères imprimables (4 × 6 bits = 24 bits), ce qui en fait un encodage sans perte et réversible.

Le Base64 a été conçu à l'origine pour les systèmes de messagerie (MIME) qui ne pouvaient transmettre que des données textuelles de manière fiable. Aujourd'hui, il est utilisé partout où les données binaires doivent transiter par des canaux textuels — des pièces jointes aux e-mails, aux charges utiles JSON, aux Data URIs HTML et aux jetons JWT.


Pourquoi encoder des images en Base64 ?

La motivation principale est d'intégrer des données d'image binaires directement dans un document texte. Un fichier PNG ou JPEG est du binaire pur ; il ne peut pas être collé dans un fichier HTML ou un objet JSON sans encodage préalable. Le Base64 résout ce problème en produisant une chaîne de texte brut qui peut être placée en toute sécurité partout où du texte est accepté.

Principales raisons pour lesquelles les développeurs utilisent l'encodage Base64

  1. Éliminer les requêtes HTTP — L'intégration d'une image supprime complètement une requête réseau. Pour les petites icônes ou les éléments décoratifs, cela peut réduire sensiblement le temps du chemin de rendu critique.
  2. Distribution en fichier unique — Les fichiers HTML autonomes (rapports, modèles d'e-mail, démos hors ligne) portent tous les actifs sans dépendances externes.
  3. Compatibilité HTML des e-mails — De nombreux clients de messagerie bloquent par défaut les chargements d'images externes pour des raisons de confidentialité. Les images Base64 intégrées contournent cette restriction.
  4. Charges utiles API — Lors de l'envoi d'une image dans un corps JSON (ex. : un endpoint d'upload d'avatar), le Base64 permet d'encoder le fichier dans un champ de chaîne.
  5. Arrière-plans CSS — De petits Data URIs intégrés dans des feuilles de style évitent des requêtes supplémentaires pour les sprites ou icônes décoratifs.
  6. Politique de sécurité du contenu (CSP) — Les images intégrées ne sont pas soumises aux restrictions d'hôte img-src de la CSP, ce qui peut simplifier la configuration dans les environnements contraints.

Comment fonctionne l'encodage Base64

L'algorithme étape par étape

Le Base64 traite l'entrée en blocs de 3 octets (24 bits à la fois) :

  1. Prendre les trois octets suivants : B1 B2 B3.
  2. Concaténer leurs bits en une chaîne de 24 bits.
  3. Diviser les 24 bits en quatre groupes de 6 bits.
  4. Mapper chaque valeur de 6 bits (0–63) sur son caractère Base64 à l'aide de la table de correspondance.
  5. Répéter jusqu'à ce que tous les octets soient traités.
  6. Ajouter des caractères = si le dernier bloc contient moins de trois octets.

Exemple

La chaîne ASCII Man (octets 0x4D 0x61 0x6E) est encodée ainsi :

M        a        n
01001101 01100001 01101110   ← 24 bits
010011  010110  000101  101110
  19      22      5      46
  T       W       F      u

Résultat : TWFu — trois octets sont devenus quatre caractères.

L'augmentation de taille de ~33% expliquée

Quatre caractères Base64 portent chacun 6 bits d'information, soit 24 bits au total. Ces mêmes 24 bits vivaient à l'origine dans trois octets (24 bits). La représentation grossit parce que chaque caractère de sortie est stocké comme un octet ASCII complet de 8 bits, et non 6 bits :

  • Entrée : 3 octets = 24 bits stockés dans 3 × 8 = 24 bits de stockage.
  • Sortie : 4 caractères stockés dans 4 × 8 = 32 bits de stockage.
  • Surcharge : 32 / 24 = 1,333… → 33,3% plus grand.

Avec la compression gzip/Brotli, le texte encodé en Base64 se compresse très bien (proche de la taille d'origine), ce qui atténue partiellement la surcharge dans les réponses HTTP.


Les Data URIs expliqués

Un Data URI (aussi appelé data URL) intègre le contenu d'un fichier directement dans une chaîne URI selon le format défini dans RFC 2397 :

data:[<mediatype>][;base64],<data>
Partie Description
data: Identifiant de schéma
<mediatype> Type MIME (ex. image/png, image/svg+xml)
;base64 Indique que les données sont encodées en Base64 (omis pour le texte brut)
,<data> La charge utile de données encodées (ou en texte brut)

Exemples

Image PNG dans une balise <img> :

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." alt="icône">

Arrière-plan SVG en CSS :

.logo {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i...");
}

SVG sans Base64 (encodé en URL) :
Le SVG est déjà du texte, il peut donc être intégré sans Base64 en utilisant l'encodage en pourcentage :

.icon {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'...%3E%3C/svg%3E");
}

L'encodage URL des SVGs produit une sortie plus petite que le Base64 pour la même image.


Exemples de code pratiques

Navigateur : API FileReader

// Convertir un fichier image en Base64 dans le navigateur
function fileToBase64(file) {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.readAsDataURL(file);
    reader.onload = () => resolve(reader.result);
    reader.onerror = reject;
  });
}

// Utilisation
const input = document.querySelector('input[type="file"]');
input.addEventListener('change', async (e) => {
  const base64 = await fileToBase64(e.target.files[0]);
  document.querySelector('img').src = base64;
});

reader.result inclut déjà le préfixe complet du Data URI (ex. data:image/png;base64,...) et peut être assigné directement à src.

Navigateur : API Canvas (redimensionner + encoder)

function resizeAndEncode(file, maxWidth = 200) {
  return new Promise((resolve) => {
    const img = new Image();
    const url = URL.createObjectURL(file);
    img.onload = () => {
      const scale = Math.min(1, maxWidth / img.width);
      const canvas = document.createElement('canvas');
      canvas.width = img.width * scale;
      canvas.height = img.height * scale;
      canvas.getContext('2d').drawImage(img, 0, 0, canvas.width, canvas.height);
      URL.revokeObjectURL(url);
      resolve(canvas.toDataURL('image/webp', 0.85));
    };
    img.src = url;
  });
}

JavaScript : Décoder le Base64 en binaire

// Décoder un Data URI Base64 en Blob
function dataURItoBlob(dataURI) {
  const [header, data] = dataURI.split(',');
  const mime = header.match(/:(.*?);/)[1];
  const binary = atob(data);
  const bytes = new Uint8Array(binary.length);
  for (let i = 0; i < binary.length; i++) {
    bytes[i] = binary.charCodeAt(i);
  }
  return new Blob([bytes], { type: mime });
}

Python : Encoder et décoder

import base64

# Encoder une image en Base64
with open("image.png", "rb") as f:
    encoded = base64.b64encode(f.read()).decode("utf-8")
    data_uri = f"data:image/png;base64,{encoded}"

print(data_uri[:80], "...")  # Aperçu

# Décoder le Base64 en image
image_data = base64.b64decode(encoded)
with open("output.png", "wb") as f:
    f.write(image_data)

CSS : Intégrer une petite icône

/* Intégrer une petite icône en CSS */
.icon {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i...");
  width: 24px;
  height: 24px;
}

/* Alternativement, encoder les petits SVGs en URL pour plus de lisibilité */
.icon-alt {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E...%3C/svg%3E");
}

Cas d'usage réels

1. Modèles d'e-mail

Les clients de messagerie comme Outlook, Gmail (dans certains contextes) et le webmail d'entreprise bloquent souvent les chargements d'images externes par défaut. Intégrer de petites images sous forme de Base64 data URIs dans le HTML garantit qu'elles s'affichent toujours, indépendamment des paramètres de confidentialité du client.

2. Applications web progressives (PWA) et apps offline-first

L'intégration d'images critiques dans le shell HTML ou les actifs mis en cache par le service worker garantit leur disponibilité hors ligne, sans entrées de cache supplémentaires.

3. Pipelines de traitement d'images basés sur Canvas

canvas.toDataURL() est le mécanisme de sortie standard pour les transformations d'images dans le navigateur — redimensionnement, filigrane, conversion de format — avant l'envoi vers un serveur.

4. Fonctionnalités d'export de données

Générer des rapports téléchargeables (PDF, ZIP, HTML) qui doivent contenir leurs images sans hébergement externe. Une facture HTML entièrement autonome peut être envoyée par e-mail ou archivée sans se soucier des liens d'images brisés.

5. Alternative aux sprites CSS pour les petites icônes

Pour les petites icônes ponctuelles, un seul SVG encodé en Base64 en arrière-plan peut être plus simple à maintenir qu'une feuille de sprites.


Comparaison : Base64 intégré vs fichier externe

Facteur Base64 Intégré Fichier Externe
Requêtes HTTP 0 (en ligne) 1 par image
Surcharge de taille ~33% plus grand Aucune
Cache navigateur Non mis en cache séparément Mis en cache par URL
Distribution CDN Non applicable Support CDN complet
Invalidation du cache Mettre à jour le document parent Changer le nom/hash du fichier
Idéal pour Petites icônes < 5 Ko Photos, grandes images
Compatibilité e-mail Excellente Souvent bloqué
Support hors ligne Intégré Nécessite un service worker

Compromis de performance et considérations

Quand le Base64 améliore les performances

  • Images très petites (< 2–5 Ko) : Le coût d'une requête HTTP (résolution DNS + handshake TCP + négociation TLS + requête/réponse) dépasse souvent la pénalité de 33% pour un petit fichier.
  • Environnements HTTP/1.1 : Les navigateurs limitent les connexions simultanées par hôte (généralement 6). La réduction du nombre de requêtes est plus impactante ici que sous HTTP/2.
  • Images critiques above-the-fold : Inliner une icône hero ou un logo signifie qu'il est rendu avec le premier octet HTML — aucun aller-retour supplémentaire.

Quand le Base64 nuit aux performances

  • Grandes images (> 5–10 Ko) : La surcharge de taille devient significative. Un PNG de 100 Ko devient ~133 Ko en Base64.
  • Images réutilisées : Un fichier image externe est téléchargé une fois et réutilisé depuis le cache sur plusieurs pages. Une chaîne Base64 intégrée dans chaque page est retéléchargée à chaque chargement.
  • Multiplexage HTTP/2 : Sous HTTP/2, de nombreuses petites requêtes sont multiplexées sur une seule connexion avec un minimum de surcharge. L'argument « éliminer les requêtes » s'affaiblit considérablement.
  • Temps d'analyse du document : Une grande chaîne Base64 contribue au temps d'analyse HTML.
  • Cache navigateur : Les Data URIs intégrés dans le HTML ne sont mis en cache que dans le cadre du document et ne peuvent pas être partagés entre les pages.

Note sur la compression

Le texte encodé en Base64 se compresse très bien avec gzip/Brotli en raison de sa haute redondance (ensemble de caractères limité, motifs répétés). Lorsque la compression HTTP est activée, la pénalité effective de taille de transfert tombe à environ 2–8% pour les images typiques.


Meilleures pratiques

  1. Définir un seuil de taille. Intégrer les images de moins de 2–5 Ko ; utiliser des URLs externes pour tout ce qui est plus grand. De nombreux bundlers (webpack, Vite) appliquent automatiquement cette règle via url-loader / asset/inline.

  2. Préférer SVG aux images raster pour les icônes. Les SVGs sont déjà du texte et se compriment mieux que le Base64 raster. Utiliser l'encodage URL (encodeURIComponent) plutôt que le Base64 pour les SVGs afin de maintenir leur lisibilité.

  3. Activer la compression HTTP. S'assurer que gzip ou Brotli est activé sur le serveur pour que la surcharge de 33% soit largement compensée en transit.

  4. Utiliser WebP ou AVIF. Les formats modernes produisent des fichiers bien plus petits avant l'encodage, ce qui rend la sortie Base64 proportionnellement plus petite.

  5. Auditer avec DevTools. Vérifier l'onglet Network. Si les images intégrées rendent le document HTML significativement plus grand, envisager de les déplacer vers des URLs externes avec CDN et en-têtes de cache longue durée.

  6. Pour les e-mails, tester sur plusieurs clients. Tous les clients de messagerie ne rendent pas les data URIs de façon identique. Tester sur Outlook, Gmail (web et app), Apple Mail et les clients mobiles avant de se fier aux images intégrées pour du contenu critique.

  7. Supprimer les métadonnées avant l'encodage. Utiliser un outil qui supprime les données EXIF avant l'intégration — EXIF peut ajouter des kilo-octets de données inutiles (et potentiellement exposer des coordonnées GPS sensibles).

  8. Utiliser des outils de compilation. Plutôt que d'encoder manuellement les images, utiliser asset/inline de webpack, le suffixe d'import ?inline de Vite, ou PostCSS postcss-inline-base64 pour automatiser le processus de manière fiable.


SVG vs images raster : une note sur l'encodage

Les images SVG sont du texte XML, ce qui signifie qu'elles peuvent être intégrées dans le CSS sans Base64 en encodant simplement le balisage en URL. Cette approche est préférée car :

  • Le résultat est plus petit que le Base64 pour le contenu SVG.
  • Le SVG reste lisible à l'intérieur de la feuille de styles.
  • Aucune surcharge de décodage.
/* SVG encodé en URL — préféré pour les SVGs */
.checkmark {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath d='M9 16.17L4.83 12l-1.42 1.41L9 19 21 7l-1.41-1.41z'/%3E%3C/svg%3E");
}

/* SVG encodé en Base64 — acceptable mais moins lisible */
.checkmark-b64 {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i...");
}

Foire aux questions (FAQ)

Q1 : Quelle est la taille maximale d'un Data URI ?

Il n'existe pas de limite standard stricte, mais les navigateurs imposent des limites pratiques. Chrome et Firefox gèrent des data URIs jusqu'à ~2 Mo sans problème. Internet Explorer limitait historiquement les data URIs à 32 Ko. Pour une utilisation en production, garder les images intégrées en dessous de 5 Ko pour éviter d'impacter le temps d'analyse du document.

Q2 : Puis-je utiliser des images Base64 dans la propriété CSS content: ?

Oui. Les pseudo-éléments acceptent les data URIs dans content: url(...) :

.badge::before {
  content: url("data:image/png;base64,...");
}

Notez que content: url() rend l'image à sa taille intrinsèque et ne peut pas être redimensionné avec width/height — utiliser background-image à la place pour le contrôle de la taille.

Q3 : L'encodage Base64 affecte-t-il la qualité de l'image ?

Non. Le Base64 est un encodage sans perte. Il encode et décode les octets originaux exacts sans aucune modification. La qualité de l'image est déterminée uniquement par le fichier image d'origine et son format (JPEG avec perte vs PNG/WebP sans perte).

Q4 : Comment décoder une chaîne Base64 en fichier ?

Dans le navigateur :

const byteString = atob(base64String); // décoder

En Python :

import base64
data = base64.b64decode(b64_string)

En Node.js :

const buf = Buffer.from(b64String, 'base64');

Q5 : Les images Base64 sont-elles indexées par les moteurs de recherche ?

Les moteurs de recherche peuvent indexer les images délivrées via des data URIs, mais ne les explorent peut-être pas aussi efficacement que les images hébergées externement. Pour les images critiques pour le SEO, les héberger en externe avec des noms de fichiers descriptifs, un texte alt approprié et un balisage de données structurées.

Q6 : Pourquoi ma chaîne Base64 se termine-t-elle par == ?

Les caractères de remplissage (=) sont ajoutés lorsque le nombre d'octets d'entrée n'est pas divisible par 3. Un = signifie que le dernier bloc avait 2 octets (16 bits → 18 bits encodés → 1 caractère de remplissage). Deux == signifient que le dernier bloc n'avait qu'1 octet (8 bits → 12 bits encodés → 2 caractères de remplissage).

Q7 : Le Base64 est-il une forme de chiffrement ?

Non. Le Base64 est purement un schéma d'encodage, pas du chiffrement. Il ne fournit aucune confidentialité — n'importe qui peut le décoder instantanément. Ne pas utiliser le Base64 pour « cacher » des données sensibles. Pour la sécurité, utiliser un vrai chiffrement (AES, RSA, etc.).

Q8 : Quelle est la différence entre Base64 et Base64url ?

Base64url est une variante du Base64 conçue pour être sûre dans les URLs. Il utilise - à la place de + et _ à la place de /, et omet le remplissage =. Il est couramment utilisé dans les JWTs et d'autres applications web où les caractères +, / et = causent des problèmes dans les paramètres d'URL.