Outil de Conversion d'Image Base64
Convertir entre images et encodage Base64, supporte le glisser-déposer et l'aperçu en temps réel
Glissez l'image ici, ou cliquez pour sélectionner un fichier
Supporte JPG, PNG, GIF, WebP, SVG et plus
Qu'est-ce que l'encodage d'image en Base64 ?
L’outil Image Base64 convertit des fichiers image en texte Base64 ou en data URL, puis peut décoder ces chaînes pour réafficher l’image. Il est pratique pour de petites icônes, des placeholders, des modèles d’e-mail, des arrière-plans CSS, des tests d’API ou des démonstrations où un fichier séparé serait encombrant. Base64 n’est pas une compression: la charge devient généralement plus lourde et le cache peut être moins efficace pour de grandes photos ou des ressources répétées. L’outil sert donc surtout à convertir, inspecter et déboguer avant de choisir entre données intégrées, CDN ou URL d’image classique.
Guide d'utilisation
Comment utiliser
- Glissez ou cliquez pour téléverser une image, détection automatique du type et des dimensions
- Choisissez le format de sortie : Data URL (prêt pour le code) ou Base64 pur
- Cliquez sur le bouton copier pour coller le résultat encodé où besoin
- Pour la conversion inverse, collez une chaîne Base64 et cliquez sur convertir pour télécharger l'image
Base64 vers image
- Collez une data URL ou une chaîne Base64 brute dans le champ de saisie, puis convertissez-la pour prévisualiser l'image décodée avant le téléchargement.
- Si le décodage échoue, vérifiez que le texte Base64 est complet et que le préfixe data:image/... est correctement formé.
Image vers Base64
- Choisissez Data URL lorsque le résultat sera collé directement dans du HTML ou du CSS, et Base64 pur lorsqu'un autre système stocke déjà le type MIME séparément.
- Gardez les images Base64 de petite taille ; les grandes images alourdissent le texte d'environ un tiers et rendent les contenus HTML, CSS ou JSON plus difficiles à maintenir.
Cas d’utilisation
Principe technique
Une image encodée en Base64 est une data URI telle que définie dans la RFC 2397 : le préfixe de schéma data:, le type MIME comme image/png, le littéral ;base64, puis la charge utile construite à partir de l'alphabet de 64 caractères A-Z, a-z, 0-9, +, /, avec = comme remplissage terminal. L'encodage prend le flux binaire trois octets à la fois et émet quatre caractères, de sorte que la charge utile croît d'un facteur fixe de 4/3 (environ 33 %) plus un ou deux caractères de remplissage lorsque le nombre d'octets n'est pas un multiple de trois. Dans le navigateur, l'encodage commence par FileReader.readAsDataURL, qui transmet le fichier via le même pipeline et renvoie l'URL data: complète, prête à être insérée dans un <img src> ou un url() de background-image CSS. Les primitives btoa et atob, qui ne manipulent que des chaînes, fonctionnent uniquement sur des charges utiles déjà binaires (latin-1 uniquement, les octets binaires doivent donc être convertis via Uint8Array). Le décodage en une image visualisable passe par atob vers un Uint8Array, puis vers un Blob avec le type MIME d'origine, et l'objet URL.createObjectURL devient une ressource HTTP classique récupérable. Le compromis pratique ne porte pas sur la bande passante mais sur la mise en cache. Chaque occurrence de la charge utile est dupliquée partout où le HTML, le CSS ou le JSON apparaît, de sorte que la ressource ne peut pas être mise en cache séparément, ne peut pas obtenir son propre ETag et est re-téléchargée à chaque document parent. Des règles strictes de Content-Security-Policy bloquent également les data: URI sauf si 'data:' est explicitement listé sous img-src ou style-src. Depuis l'arrivée du multiplexage HTTP/2, l'intégration de petites icônes en ligne bat rarement une requête séparée ; la règle moderne est donc de n'intégrer en ligne que les ressources de moins de 2 Ko environ et de conserver les images principales et les sprites réutilisables comme fichiers mis en cache.
- Schéma Data URI : format RFC 2397 data:[<mime>][;base64],<charge> ; la virgule est obligatoire et constitue l'erreur de copier-coller la plus fréquente.
- Surcoût d'encodage : 3 octets binaires deviennent 4 caractères ASCII, la charge utile augmente donc d'un facteur 4/3 (~33 %) plus jusqu'à 2 caractères de remplissage '='.
- API navigateur : FileReader.readAsDataURL pour les fichiers ; btoa/atob pour les charges utiles déjà en texte (latin-1 uniquement, les données binaires nécessitent un pont Uint8Array).
- Chemin de décodage : atob → Uint8Array → new Blob([buf], {type}) → URL.createObjectURL fournit une URL d'asset récupérable classique au lieu d'une chaîne figée.
- Piège CSP : une politique img-src ou default-src stricte bloque les data: sauf si le mot-clé est explicitement listé, ce qui casse silencieusement les images intégrées en production.
- Compromis de cache : les données intégrées n'ont pas d'ETag ni d'entrée de cache indépendante, le multiplexage HTTP/2 bat donc généralement l'intégration en ligne pour tout ce qui dépasse ~2 Ko.
Exemples
Utilisation en HTML
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=" alt="pixel transparent 1x1" width="16" height="16" />Utilisation en CSS
.icon-search {
width: 16px;
height: 16px;
background-image: url('data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxNiAxNiI+PHBhdGggZD0iTTYgMmE0IDQgMCAxIDAgMi4yNCA3LjMzbDMuMjEgMy4yMSAxLjQyLTEuNDItMy4yMS0zLjIxQTQgNCAwIDAgMCA2IDJ6Ii8+PC9zdmc+');
background-size: contain;
}Transmission via une API JSON
POST /api/v1/avatar
Content-Type: application/json
{
"userId": 10086,
"avatar": {
"mimeType": "image/png",
"data": "iVBORw0KGgoAAAANSUhEUgAAAAUA..."
}
}
// Note : Base64 augmente la taille d'environ 33 % ; pour les fichiers > 100 Ko, préférez multipart/form-data.FAQ
L'image est-elle téléchargée ?
Non. L'image est lue avec l'API FileReader et encodée en Base64 dans votre navigateur. Les octets ne quittent jamais votre appareil. Surveillez l'onglet Réseau pendant la conversion pour le confirmer.
Pourquoi la chaîne Base64 est-elle environ 33 % plus longue que le fichier ?
Base64 représente 3 octets d'entrée par 4 caractères ASCII, donc taille_encodée = ceil(taille_fichier / 3) * 4. Cela représente environ 33 % de surcharge, le coût de la représentation du binaire en texte imprimable.
Comment utiliser le résultat en HTML ou CSS ?
Utilisez une URI de données : <img src="data:image/png;base64,..."> en HTML ou background-image: url(data:image/png;base64,...) en CSS. La page génère l'URI de données complète pour vous. Utile pour de minuscules ressources en ligne, mais cela gonfle la taille des fichiers HTML/CSS et contourne la mise en cache des images du navigateur.
Quel est le seuil de taille pour intégrer en ligne plutôt que de lier ?
En dessous de ~5 Ko, l'intégration en ligne gagne généralement (économise une requête HTTP). Au-delà, le fichier devrait être une ressource séparée pour des raisons de mise en cache. Au-dessus de ~50 Ko, l'intégration en ligne gonfle considérablement votre HTML. Différents outils de build utilisent différents seuils ; webpack utilise 8 Ko par défaut.
Puis-je décoder une chaîne Base64 pour récupérer une image ?
Oui. Collez une URI data: ou du Base64 brut (avec le type MIME image/*) et la page reconstruit l'image et propose le téléchargement. Utile lorsque vous trouvez une image intégrée dans le code source et souhaitez le fichier original.
Les SVG et GIF animés sont-ils pris en charge ?
Oui. Le SVG peut être encodé directement ou avec du texte URL-encodé (qui est plus court que le Base64 pour les SVG-XML). Les GIF animés sont encodés en une seule chaîne Base64 ; le résultat reste animé. WebP, AVIF et autres formats modernes fonctionnent de la même manière.
Dois-je encoder en Base64 de grandes photos pour des e-mails ?
L'e-mail lui-même encode déjà les pièces jointes en Base64 via MIME, donc vous n'avez pas besoin de les pré-encoder. Coller une chaîne Base64 dans le corps de l'e-mail rend simplement le message plus volumineux et illisible pour la plupart des clients. Joignez le fichier normalement.