Aller au contenu principal

Convertir une image en Base64

Image en Base64 transforme une image en bloc de texte que vous pouvez coller directement dans votre code. Ce texte est une data URI, valide en CSS, HTML, JSON et Markdown, et il embarque l’image entière — la page n’a donc besoin d’aucun fichier séparé et ne fait aucune requête supplémentaire pour elle. Le texte est environ 33% plus long que le fichier, ce que la page vous affiche, car ce coût est précisément la raison de réfléchir avant d’inliner.

100 % local

Déposez une image ici

ou n’importe où sur la page · Choisir un fichier · 100 Mo

Acceptés : JPG, JPEG, PNG, WebP, AVIF, GIF, SVG, ICO

Déposez un PNG, JPG, SVG ou une icône pour obtenir une URI de données et des extraits prêts à l’emploi.

Comment fonctionne Convertir une image en Base64 ?

Une data URI est un fichier inliné à l’endroit qui le référence. Au lieu que src="logo.png" pointe vers quelque chose que le navigateur doit aller chercher, les octets de l’image sont écrits dans l’attribut lui-même. Aucune requête, aucun second fichier, rien qui puisse renvoyer un 404.

Pourquoi base64 plutôt que les octets bruts

Parce que les endroits où vont ces chaînes — un fichier CSS, un attribut HTML, une valeur JSON — sont du texte, et qu’un PNG n’en est pas. Ses octets contiennent des guillemets, des retours à la ligne, des octets nuls et tout ce qui mettrait fin à une chaîne ou corromprait un document. Base64, défini dans la RFC 4648, fait correspondre chaque groupe de trois octets à quatre caractères issus d’un alphabet de 64 symboles sûr partout, avec un remplissage par = quand l’entrée ne se divise pas également.

Quatre caractères pour trois octets, voilà d’où vient le 33%. Ce n’est pas un surcoût qu’un meilleur encodeur pourrait supprimer ; c’est de l’arithmétique.

Quand inliner vaut le coup

Pour les petits assets utilisés immédiatement : une icône dans une règle CSS, un spacer de 1 × 1, un logo dans un e-mail HTML où les images externes sont bloquées par défaut, un placeholder qui doit s’afficher avant tout le reste. Dans tous ces cas, la requête que vous économisez coûte plus cher que les 33% que vous dépensez — une requête entraîne du DNS, l’établissement de la connexion et une latence aller-retour, et sur une connexion mobile cela fait des dizaines de millisecondes pour un fichier qui serait passé en un seul paquet.

Quand c’est une erreur

Pour tout ce qui est volumineux ou réutilisé. Une data URI ne peut pas être mise en cache indépendamment : inlinez une image hero de 200 KB dans votre feuille de style et chaque visiteur la retélécharge à chaque modification de n’importe quelle règle de ce fichier. Elle ne peut pas être récupérée en parallèle non plus — elle fait partie du document, donc elle est téléchargée avant la fin du document, bloquant le rendu qu’elle était censée accélérer. Et elle ne peut pas être chargée en lazy loading, redimensionnée par un CDN, ni servie en WebP aux navigateurs qui le prennent en charge.

La règle approximative, c’est quelques kilooctets. En dessous, inliner gagne en général ; au-delà d’environ 10 KB, cela perd en général, et cette page le dit quand vous franchissez la limite.

Content Security Policy

Une CSP stricte bloque les data URI si vous ne les autorisez pas. Les images ont besoin de img-src 'self' data: ; une police inlinée de la même manière a besoin que font-src autorise data: aussi. C’est bon à savoir avant d’inliner quelque chose et de le voir manquant uniquement en production, là où la CSP est appliquée.

Base64 n’est pas du chiffrement

Cela mérite d’être dit clairement, tant la confusion est fréquente : base64 est un encodage, réversible par n’importe qui, sans aucune clé. Tout ce qui est inliné de cette façon reste aussi lisible qu’avant. Cela ne cache rien.

Où cela s’exécute

Dans votre navigateur. Le fichier est lu avec un FileReader et encodé localement — rien n’est envoyé, ce qui, pour une image que vous vous apprêtez à intégrer dans votre propre code source, est la seule disposition sensée.

Entrée

icon.png — 1.2 KB
image/png

Sortie

data:image/png;base64,iVBORw0KGgo…
1.6 KB (+33%)
no HTTP request

Quelles options et quels cas limites Convertir une image en Base64 prend en charge ?

Référence technique et options
ParamètreTypeValeur par défautComportement et cas limites
URI de donnéesdata:…par défautL’URI brute. À coller là où une URL est attendue.
CSSbackground-image—Une rèête prête à être ajoutée dans une feuille de style.
HTML<img>—Un élément img avec l’attribut alt à compléter par vous-même.
JSONstring—Entre guillemets correctement, pour une charge API ou un fichier de fixture.
Markdown![]()—Syntaxe d’image, pour un README qui doit être autonome.
Base64 uniquementsans préfixe—Les octets encodés seuls, pour un champ qui ajoute son propre type MIME.
Coût en taille+33%—Quatre caractères de sortie pour trois octets d’entrée. Calcul arithmétique, pas de surcharge.
CSPimg-src data:—Une politique stricte bloque les URI de données jusqu’à ce que cela soit autorisé.

Questions fréquentes

Pourquoi le base64 est-il plus gros que l’image ?

Parce que base64 représente trois octets avec quatre caractères, soit une hausse de 33% par construction. L’alphabet compte 64 symboles, donc chaque caractère porte six bits ; trois octets font vingt-quatre bits, soit exactement quatre caractères. Aucun encodeur ne peut faire mieux tout en restant dans un alphabet compatible texte. Si la taille compte, compressez l’image avant de l’encoder — c’est là que se trouvent les économies.

Faut-il inliner les images en data URI ?

Les petites, oui : icônes, spacers, un logo dans un e-mail HTML, tout ce qui fait moins de quelques kilooctets et dont on a besoin immédiatement. La requête économisée coûte généralement plus cher que les 33% dépensés. Les grosses, non : une data URI ne peut pas être mise en cache séparément, ne peut pas être téléchargée en parallèle et bloque le document ou la feuille de style qui la contient — ainsi, une image hero de 200 KB inlinée est retéléchargée à chaque modification du fichier qui la contient, et retarde le rendu qu’elle était censée accélérer.

Le chiffrement base64 protège-t-il l’image ?

Base64 n’est pas du chiffrement. C’est un encodage de texte réversible et sans clé, conçu pour faire passer des données binaires par des canaux qui n’acceptent que du texte. N’importe qui peut le décoder en une ligne dans la console du navigateur. Il n’offre aucune confidentialité, et le considérer comme tel est une source récurrente de vrais incidents de sécurité.

Pourquoi ma data URI est-elle bloquée par la Content Security Policy ?

Parce qu’une CSP stricte traite data: comme une source qui doit être autorisée explicitement. Pour les images, il faut que img-src inclue data: ; pour une police inlinée, font-src en a besoin aussi. La panne passe facilement inaperçue en développement, où la CSP est souvent non appliquée, et n’apparaît qu’en production — vérifiez donc la politique avant de vous lancer dans l’inlining.

Puis-je décoder une data URI pour retrouver un fichier ?

Oui. Tout ce qui suit la virgule est du base64 ; décodez-le et vous retrouvez les octets d’origine, à l’octet près — l’encodage est sans perte dans les deux sens. L’outil Encodeur / Décodeur Base64 de ce site gère le côté texte de l’opération, et n’importe quel navigateur affichera une data URI collée directement dans la barre d’adresse.

L’image est-elle envoyée pour être encodée ?

Non. Le fichier est lu par le FileReader de votre navigateur et encodé dans cet onglet ; rien n’est transmis. Cela compte ici, d’une manière qu’il est facile d’oublier — les images que l’on encode en base64 sont généralement des assets d’un projet en cours, et rien ne justifie qu’elles voyagent.