Encodez un fichier PNG, JPEG, WebP, GIF, AVIF, BMP ou ICO en data URI Base64. Le format est lu dans les octets du fichier, l'aperçu est généré à partir de l'URI produite et le surcoût de taille est mesuré, pas supposé.
Rien n'est encore chargé
Ou collez-en une depuis le presse-papiers avec ⌘V / Ctrl+V. PNG, JPEG, WebP, GIF, AVIF, BMP, ICO et SVG sont reconnus d'après leurs propres octets, pas d'après le nom du fichier.
10 MB maximum · une image à la fois · jamais importée
Chaque format ci-dessous possède une signature dans ses premiers octets, et c'est elle qui détermine le type MIME de votre URI. Un PNG renommé en .jpg est encodé comme un PNG, car déclarer le mauvais type produit une URI qui s'affiche dans un navigateur et échoue discrètement dans le suivant.
L'image ci-dessous est chargée depuis la chaîne encodée elle-même, sur un damier pour rendre la transparence visible. Si elle s'affiche ici, elle s'affichera dans votre page.
Chargez une image et elle apparaîtra ici, affichée à partir de la chaîne exacte que vous donnent les boutons de copie.
L'encodage fonctionne toujours. Savoir s'il faut le faire est une autre question, et la réponse dépend de la taille de la chaîne finale et de ce qu'elle fait au fichier où elle atterrit.
Chargez une image et le verdict apparaîtra ici, classé selon la taille de l'URI finale plutôt que celle du fichier.
Une image intégrée n'a pas d'URL, or tout ce que la plateforme propose pour les images s'adresse à une URL : srcset et sizes, loading="lazy", fetchpriority, preload et un CDN capable de redimensionner à la demande. Dans une chaîne, rien de tout cela ne s'applique.
Un fichier est mis en cache une fois et réutilisé jusqu'à ce qu'il change. Une image intégrée n'est mise en cache que comme partie de son fichier hôte, donc modifier une seule règle CSS renvoie toutes les images de cette feuille de style, et référencer deux fois la même ressource l'envoie deux fois.
Le texte se compresse bien, mais le Base64 d'un PNG ou d'un JPEG déjà compressé non : les octets source sont quasi aléatoires, et l'encodeur ajoute un tiers avant même que gzip ne les voie. Attendez-vous à récupérer quelques pour cent, pas le surcoût.
Une longue charge utile est affichée sans sa partie centrale pour que la page reste utilisable. Chaque bouton de copie fournit la chaîne complète.
Chargez une image et cinq résultats prêts à copier apparaîtront ici : la data URI, la charge utile Base64 brute, une déclaration background-image, une balise image avec sa taille en pixels et une image Markdown.
Une illustration vectorielle, c'est du texte : l'encodage URL la garde lisible et proche de sa taille d'origine au lieu de lui ajouter un tiers.
Encodez une police, une archive ou du texte brut, ou décodez une chaîne Base64 que quelqu'un vous a transmise.
Réduisez d'abord l'image source ; chaque octet supprimé avant l'encodage, c'est 1.33 octet de moins dans la chaîne finale.
Une data URI transporte le fichier entier dans la référence, si bien que le code qui désigne l'image la contient déjà. Pour un format binaire, cela veut dire Base64 : trois octets deviennent quatre caractères imprimables, une hausse fixe d'un tiers en échange d'une chaîne qui traverse n'importe quelle feuille de style, n'importe quel modèle ou champ JSON sans autre échappement. Cette page lit le fichier dans votre navigateur, l'identifie d'après ses premiers octets plutôt que d'après son nom, affiche le résultat à partir de l'URI produite, puis vous dit franchement si le compromis en vaut la peine pour cette image précise.
Déposez un fichier sur le panneau, choisissez-en un avec le sélecteur ou collez une capture d'écran directement depuis le presse-papiers. Il est lu dans cet onglet, et le plafond de 10 MB maintient la chaîne encodée à une taille qu'un navigateur peut encore gérer.
L'en-tête est comparé à la signature de chaque format pris en charge, donc un fichier renommé est tout de même encodé selon sa vraie nature. L'aperçu est ensuite dessiné à partir de l'URI générée, et c'est là qu'un téléchargement tronqué se trahit.
La data URI complète, la charge utile Base64 brute, une déclaration background-image, une balise image portant la taille en pixels décodée ou une image Markdown. Le verdict à côté indique si intégrer ce fichier précis est une bonne idée.
Chaque format pris en charge est identifié par ses octets magiques plutôt que par son extension ou le type deviné par le navigateur. C'est important, car un type MIME erroné dans une data URI ne lève aucune erreur : l'image s'affiche dans un navigateur et rien n'apparaît dans le suivant.
Quatre caractères pour trois octets, plus jusqu'à deux caractères de remplissage, plus le préfixe. Le panneau détaille chacun de ces éléments pour le fichier chargé, si bien que le chiffre est un calcul vérifiable et non un tiers retenu de mémoire.
Sous un kilo-octet, l'intégration supprime une requête qui coûte plus cher que la charge utile. Au-delà de quarante, elle gonfle un fichier bloquant le rendu pour économiser un téléchargement parallèle. Chaque palier s'accompagne de son raisonnement, pour que vous puissiez le contester en connaissance de cause.
L'aperçu charge l'URI encodée elle-même sur un damier, si bien que la transparence est visible et qu'un fichier corrompu échoue ici plutôt qu'en production. Sa taille en pixels décodée est inscrite dans la balise image pour éviter les décalages de mise en page.
Les fichiers non pris en charge sont identifiés au lieu d'être refusés sans explication, car savoir que vous avez fourni un HEIC (qu'aucun navigateur ne sait afficher) fait toute la différence entre le convertir et fixer un cadre vide.
Le fichier est lu avec la File API du navigateur et encodé en mémoire à partir de ces octets. Aucune importation, aucune file d'attente, aucune requête, aucune conservation : une ressource non publiée reste sur votre machine.
C'est le fichier entier réécrit sous forme d'URL. La chaîne commence par data:image/png;base64, et tout ce qui suit la virgule correspond aux octets du fichier écrits dans l'alphabet de 64 caractères composé de lettres, de chiffres, du signe plus et de la barre oblique. Comme l'image voyage dans la référence, ce qui a chargé la feuille de style ou le HTML dispose déjà de l'image, et aucune seconde requête n'est faite pour elle.
Parce que les octets sont binaires. L'encodage pourcent laisse l'ASCII imprimable tel quel et dépense trois caractères pour tout le reste, ce qui est une aubaine pour du balisage et un désastre pour un PNG : les données d'image compressées sont quasi aléatoires, donc presque chaque octet devrait être échappé et la chaîne approcherait le triple de la taille du fichier. Base64 applique un tarif fixe de quatre caractères pour trois octets quel que soit le contenu, et son alphabet ne demande aucun échappement supplémentaire en CSS, HTML ou JSON. Pour le SVG, qui est du texte, le compromis s'inverse, et c'est pourquoi ce format a sa propre page ici.
Pour une petite ressource sur le chemin critique, en général oui : une requête a des coûts fixes (établissement de la connexion, en-têtes, latence) qui écrasent le poids d'une icône de 600 octets. Au-delà, la réponse devient vite négative. Les octets rejoignent un fichier qui bloque le rendu, ils sont retéléchargés chaque fois que ce fichier change, ils ne peuvent être ni chargés en différé ni rendus moins prioritaires, et ils ne peuvent pas être récupérés en parallèle comme le serait une URL séparée. L'intégration échange une requête contre du poids au mauvais endroit ; elle n'est rentable que tant que ce poids reste négligeable.
La charge utile fait ceil(bytes / 3) × 4 caractères (une hausse fixe de 33.3% avant arrondi), plus le remplissage nécessaire pour atteindre un multiple de quatre, plus le préfixe data:…;base64, d'environ vingt octets. Un PNG de 10 KB devient environ 13.4 KB de texte. La compression n'y change rien non plus : gzip et brotli exploitent les répétitions, et une image déjà compressée n'en contient presque plus, donc vous récupérez quelques pour cent, pas le surcoût.
PNG, JPEG, WebP, GIF, AVIF, BMP et ICO s'encodent et s'affichent tous en data URI, et le SVG est accepté ici aussi, même si sa place est sur la page dédiée au SVG. Le refus notable est HEIC : c'est le format qu'un iPhone enregistre par défaut et aucun navigateur ne sait le décoder, donc en encoder un ne produirait qu'une URI qui ne s'affiche nulle part. Même chose pour TIFF, PDF et les fichiers RAW d'appareil photo. Convertissez-les d'abord en PNG ou JPEG, puis encodez le résultat.
Les octets. Une extension est une convention de nommage que n'importe qui peut modifier, et les fichiers sont renommés en permanence : une capture PNG enregistrée en .jpg, un WebP téléchargé avec le suffixe .png. Chaque format d'image commence par une signature fixe, donc l'en-tête fait foi et c'est lui que cette page utilise. Si vous écrivez dans l'URI le type MIME de l'extension, les navigateurs ne s'accordent pas sur le fait d'analyser le contenu ou de se fier à la déclaration, et c'est ainsi qu'une image finit par s'afficher sur votre machine et pas sur celle de quelqu'un d'autre.
Comme favicon, oui : <link rel="icon" href="data:image/png;base64,…"> fonctionne dans tous les navigateurs actuels et économise une requête au premier affichage. Pour l'e-mail, c'est l'inverse : Outlook ignore purement et simplement les data URI et Gmail les supprime, donc les images intégrées à un e-mail exigent toujours une pièce jointe CID ou une URL hébergée. Bon à savoir aussi : depuis 2017, les navigateurs bloquent la navigation directe vers les URL data:, donc en coller une dans la barre d'adresse pour la vérifier ne fonctionnera pas. Utilisez plutôt l'aperçu ci-dessus.
Pas de façon significative dans les navigateurs modernes : une data URI de plusieurs mégaoctets se charge depuis une feuille de style ou une balise image. Les limites qui comptent sont pratiques. Cette page plafonne l'entrée à 10 MB, car la chaîne encodée doit tenir dans la mémoire de l'onglet et dans le DOM. Au-delà, les bundles minifiés et les source maps deviennent illisibles, certains champs de CMS et de bases de données tronquent les valeurs longues sans prévenir, les DevTools rament quand vous inspectez l'élément, et chaque kilo-octet est renvoyé avec le fichier qui le contient.
Découvrez une collection grandissante pour les calculs, les documents, la rédaction et le travail de tous les jours.