Convertisseur image → Base64, gratuit

Comment ça marche

1. Déposez ou sélectionnez une image. Le navigateur lit le fichier localement avec l'API FileReader. Rien n'est envoyé où que ce soit.
2. L'encodeur convertit les octets à l'aide de l'alphabet Base64 standard : chaque groupe de 3 octets d'entrée devient 4 caractères ASCII tirés de A-Z a-z 0-9 + /, avec jusqu'à deux caractères de remplissage = en fin quand la longueur d'entrée n'est pas un multiple de 3.
3. Copiez ce dont vous avez besoin. « Copier le Base64 » vous donne uniquement la chaîne encodée (utile pour les charges utiles JSON ou le traitement côté serveur). « Copier l'URI de données » vous donne la forme complète data:image/png;base64,… prête à être déposée dans un attribut <img src> ou un background-image: url(…) CSS.
4. Collez-le là où il doit aller. La sortie est du texte brut : elle fonctionne en HTML, CSS, JSON, JavaScript, Markdown, ou partout ailleurs où une chaîne peut vivre.

Ce que fait réellement le Base64

Le Base64 est défini dans la RFC 4648 (octobre 2006). L'encodage prend 24 bits d'entrée à la fois (trois octets) et les réécrit sous forme de quatre index de 6 bits dans un alphabet de 64 caractères. Le calcul est exact : 3 octets (24 bits) → 4 caractères (portant chacun 6 bits). Quand la longueur d'entrée n'est pas un multiple de 3, l'encodeur ajoute des caractères de remplissage = pour rendre la longueur de sortie multiple de 4.

Deux conséquences pratiques :

• La sortie est toujours ~33 % plus volumineuse que l'entrée. Le ratio 4/3 est fondamental dans l'algorithme. Une image de 100 Ko devient ~133 Ko en Base64. Avec des sauts de ligne de 76 caractères façon MIME, le surcoût approche les 37 %.
• La sortie est sûre dans tout contexte textuel. L'alphabet de 64 caractères est l'intersection de tous les canaux de texte ASCII courants : HTML, JSON, XML, e-mail, URL (avec la variante sûre pour les URL), code source. C'est toute la raison d'être du Base64 : déplacer des données binaires à travers des systèmes conçus pour le texte.

La RFC 4648 §12 énonce une non-fonctionnalité importante : « L'encodage Base64 masque visuellement des informations autrement faciles à reconnaître, comme des mots de passe, mais ne fournit aucune confidentialité computationnelle. » N'importe qui peut décoder une chaîne Base64 en deux lignes de code dans n'importe quel langage. C'est de l'encodage, pas du chiffrement.

Les URI de données : la forme d'image intégrée

Une « URI de données » est le format d'enveloppe qui permet à une chaîne Base64 de prendre la place d'une URL d'image. La RFC 2397 (1998) en définit la syntaxe :

data:[<mediatype>][;base64],<data>

Pour les images, cela donne data:image/png;base64,iVBORw0KGgo… dans un attribut <img src> ou background-image: url("data:image/svg+xml;utf8,<svg…>") en CSS. Le jeton ;base64 indique au navigateur que la partie données est encodée ; sans lui, les données sont prises comme du texte en encodage-pourcent. La RFC 2397 note elle-même que les URI de données ne sont « utiles que pour de courtes valeurs », une remarque qui s'est muée en règle de performance stricte.

Quand intégrer une image en Base64

• Artefacts à fichier unique. Une signature d'e-mail avec un logo intégré qui doit survivre au transfert. Une démo HTML autonome pour CodePen, JSFiddle, ou une repro de rapport de bogue. Un PDF généré où l'image doit être intégrée pour que le fichier fonctionne hors ligne.
• Petites icônes du chemin critique. Un chevron ou un indicateur de chargement de 200 octets intégré dans le CSS critique peut se charger plus vite que de déclencher une requête HTTP distincte, surtout sur les connexions lentes.
• Réponses JSON / d'API en ligne. Téléversements d'avatars, signatures, échantillons d'OCR, codes QR générés, tout ce où le consommateur d'API attend les octets en ligne plutôt qu'une URL distincte à récupérer.
• Iframes en bac à sable ou autres contextes qui interdisent le chargement de ressources externes.
• Fichiers de configuration où vous ne voulez pas d'un fichier image voisin à côté du JSON / TOML / YAML.

Quand ne pas intégrer une image en Base64

Pour la plupart des sites web en production, une image Base64 intégrée est plus lente qu'une référence <img> normale. Cinq raisons qui se cumulent :

1. 33 % de surcoût de taille, toujours. Chaque octet coûte 4/3 octets après encodage. Une fois gzip appliqué, le surcoût apparent diminue (parce que le Base64 est répétitif), mais les octets que le navigateur analyse restent 33 % plus volumineux que l'original.
2. L'image ne peut pas être mise en cache séparément. Un image.png externe est récupéré une fois et réutilisé sur chaque page qui le référence. Une image Base64 vit à l'intérieur du HTML ou du CSS et est retéléchargée à chaque modification de ce fichier.
3. Ralentit l'analyse du HTML et du CSS. De longues chaînes intégrées dans du CSS bloquant le rendu repoussent le chemin critique. Harry Roberts (CSS Wizardry) a mesuré une vraie feuille de style cliente à 925 Ko avec des images Base64 contre 708 Ko sans, et 232 Ko compressée en gzip contre 68 Ko. Retirer le Base64 a réduit le CSS gzippé de 70,68 %.
4. Ne peut pas être chargée à la demande. L'attribut loading="lazy" diffère la récupération d'une image jusqu'à ce que l'utilisateur fasse défiler à proximité. Les images Base64 sont déjà dans le document : il n'y a rien à différer.
5. HTTP/2 et HTTP/3 ont déjà résolu le problème des « trop nombreuses requêtes ». Le multiplexage permet à une seule connexion de livrer des centaines de fichiers en parallèle, de sorte que la justification d'origine de l'intégration a largement disparu.

Une règle empirique pratique, issue de PageSpeed de Google et de la plupart des auteurs spécialisés en performance : n'intégrez que si l'image fait moins de ~1-2 Ko une fois encodée, et seulement si elle apparaît au-dessus de la ligne de flottaison dans le CSS critique. Tout ce qui est plus volumineux se comporte presque certainement mieux en fichier séparé.

SVG : utilisez l'encodage UTF-8, pas le Base64

Le SVG est déjà du texte, donc l'encoder en Base64 gaspille ~33 % des octets sans aucun bénéfice. La forme plus compacte est l'UTF-8 encodé en URL :

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

La plupart des outils de build modernes (le postcss-inline-svg de PostCSS, le svg-url-loader de Webpack) émettent la forme encodée en URL par défaut. Pour le SVG intégré, préférez cette forme au Base64, sauf si un consommateur précis exige ;base64.

Types MIME que cet outil reconnaît

Le préfixe de type de média de l'URI de données est ce qui indique au consommateur comment interpréter les octets. Le navigateur le détecte d'après le fichier que vous choisissez :

Notes de confidentialité et de sécurité

La plupart des sites « image vers Base64 » en ligne envoient votre fichier vers leur serveur, l'encodent là-bas et vous renvoient le résultat. Cela signifie que des captures d'écran d'interfaces avant lancement, des maquettes sous accord de confidentialité, des photos d'enfants, des scanners médicaux ou des signatures sur des contrats transitent par l'infrastructure d'un tiers. Cet outil encode localement : le FileReader du navigateur lit le fichier en mémoire, l'encodeur s'exécute en JavaScript sur votre appareil, et la seule chose qui quitte la page est la chaîne encodée lorsque vous la copiez.

Deux notes sur la Content Security Policy à connaître si vous livrez des images Base64 en production :

• Les images Base64 intégrées contournent les règles img-src sauf si vous les autorisez explicitement. Une CSP stricte comme img-src 'self' bloque les URI data:. Pour les autoriser, écrivez img-src 'self' data:.
• Cela vaut aussi pour les images de fond intégrées en CSS. Si une CSP bloque vos arrière-plans intégrés, vérifiez d'abord la directive img-src.

Erreurs courantes

1. Considérer le Base64 comme une obfuscation. Il n'en est rien. N'importe qui peut le décoder en deux lignes dans n'importe quel langage. Ne placez pas d'identifiants, de clés d'API ou de données sensibles dans des chaînes Base64 « pour les masquer ».
2. Intégrer une image héroïque de 200 Ko. L'image devient 266 Ko une fois encodée, se retrouve coincée dans le HTML, ne peut pas être mise en cache séparément, ne peut pas être chargée à la demande, et le premier rendu de la page est visiblement plus lent. Servez-la comme un fichier normal.
3. Copier le Base64 brut alors qu'il vous fallait l'URI de données. Une simple chaîne Base64 dans un attribut <img src> s'affiche comme cassée : il vous faut le préfixe data:image/png;base64,. Utilisez le bouton « Copier l'URI de données ».
4. Encoder du SVG en Base64. Le SVG est déjà du texte. Encodez-le plutôt en URL et économisez les 33 % de surcoût.
5. Oublier la CSP. Un img-src 'self' strict bloque les URI de données. Ajoutez data: à la directive si vous livrez des images Base64.
6. Essayer de décoder une chaîne Base64 avec un préfixe data: en tête. La portion data:image/...;base64, est une métadonnée ; retirez-la avant de passer la chaîne à un décodeur Base64.
7. Coller des images confidentielles dans un encodeur côté serveur. Si l'URL indique « encode » mais que l'onglet réseau montre un POST, votre image vient de quitter votre machine.

Foire aux questions

Quelle est la différence entre « Base64 » et « URI de données » ?

Le Base64 est l'encodage (une chaîne comme iVBORw0KGgo…). Une URI de données est l'enveloppe qui transforme une chaîne Base64 en quelque chose qui peut tenir lieu d'URL d'image : data:image/png;base64,iVBORw0KGgo…. L'enveloppe indique au navigateur le type de média et l'encodage, afin qu'il sache comment interpréter les octets. Les deux boutons de cet outil vous donnent chacune des formes séparément.

Le Base64 est-il sûr ?

Non, et ce n'est pas son rôle. Le Base64 est de l'encodage, pas du chiffrement. La RFC 4648 §12 le dit clairement : il « ne fournit aucune confidentialité computationnelle ». N'importe qui peut décoder une chaîne Base64 instantanément. Si vous avez besoin de confidentialité, chiffrez d'abord les données (avec AES, etc.) puis encodez le texte chiffré en Base64 pour le transport.

Quelle taille l'image peut-elle avoir ?

Il n'y a pas de limite stricte imposée par l'outil, puisque l'encodage se fait dans la mémoire de votre navigateur. Le plafond pratique est ce que votre appareil peut contenir : en général, des dizaines de Mo passent sans problème sur les ordinateurs portables modernes. La contrainte la plus forte est la prise en charge côté consommateur : de nombreux clients de messagerie, navigateurs et API ont leurs propres limites de taille d'URI de données, et intégrer quoi que ce soit au-delà de quelques Ko a rarement du sens pour la performance.

Pourquoi ma chaîne Base64 est-elle 33 % plus volumineuse que le fichier ?

Parce que chaque caractère Base64 porte 6 bits, tandis que chaque octet d'entrée porte 8 bits. La plus petite unité que le Base64 peut représenter sans reste est de 3 octets (24 bits = quatre caractères de 6 bits), de sorte que le ratio de sortie est exactement 4/3 ≈ 1,33. Il n'existe aucune variante de Base64 qui évite cela : c'est mathématiquement inscrit dans l'encodage.

L'image encodée fonctionnera-t-elle dans un e-mail HTML ?

Le plus souvent, mais pas toujours. Apple Mail, le Gmail moderne et la plupart des webmails affichent proprement les images data:. Microsoft Outlook pour ordinateur a toujours eu une prise en charge inconstante : certaines versions affichent bien les URI de données, d'autres les retirent entièrement. Testez sur votre liste de clients cibles avant de compter sur des images Base64 dans des e-mails transactionnels. Pour une large compatibilité, les URL d'images hébergées restent le pari le plus sûr.

Devrais-je plutôt utiliser base64url (avec - et _) ?

Seulement si vous placez les données encodées dans une URL ou un nom de fichier où + et / devraient sinon être encodés en pourcent. Pour les attributs HTML <img src> et les valeurs CSS background-image, l'alphabet standard convient. La RFC 4648 §5 définit la variante sûre pour les URL explicitement pour ces cas d'URL/nom de fichier, et avertit qu'elle « ne devrait pas être désignée seulement comme 'base64' » pour éviter la confusion avec l'alphabet standard.

Outils associés