Convertisseur Image vers Base64 - Encoder des Images en URI de Données

Parce que le Base64 est un encodage, pas un compresseur. Il représente 3 octets binaires à l'aide de 4 caractères ASCII imprimables, donc la sortie est toujours environ 33 % plus longue que l'entrée, plus quelques octets pour le préfixe data:. Cette croissance est inhérente au format et aucun réglage ne permet de l'éviter. Si vous avez besoin d'un fichier plus petit, compressez l'image avant de l'encoder — l'étape d'encodage ne peut qu'ajouter du poids.

Intégrez quand la ressource est petite et toujours nécessaire : icônes, espaceurs 1x1, minuscules textures de fond, environ moins de 10 Ko. En dessous de ce seuil, économiser une requête HTTP l'emporte généralement sur la pénalité de 33 % de taille. N'intégrez pas de photos, d'images hero, ni rien au-dessus d'environ 100 Ko. Une grande URI de données ne peut pas être mise en cache indépendamment, doit être re-téléchargée à chaque révision de page ou de feuille de style, et bloque l'analyseur jusqu'à ce qu'elle ait été lue en entier.

Souvent non. Gmail retire purement et simplement les URI de données des balises img, et les clients de bureau d'Outlook ne les ont jamais prises en charge de façon fiable. Apple Mail et certains webmails les affichent bien. L'approche fiable pour l'e-mail reste une URL d'image hébergée, ou une pièce jointe CID référencée avec cid: dans le src. Testez dans les clients que vos destinataires utilisent réellement avant de compter sur des données intégrées.

Oui, et c'est sans perte — les octets décodés sont identiques au fichier d'origine, y compris les données EXIF et le profil colorimétrique. Collez une URI de données complète dans la barre d'adresse d'un navigateur et l'image s'affiche. En code, atob() en JavaScript ou base64 -d en ligne de commande fait l'affaire. Notez que la sortie brute de cette page omet le préfixe data:, ajoutez-le donc si la cible attend une URI complète.

Non. Le SVG est déjà du texte, donc le Base64 ajoute 33 % pour rien. Collez plutôt le balisage directement dans votre HTML, ce qui permet aussi au CSS de styliser les formes et au JavaScript de les atteindre. Pour les fonds CSS, utilisez un SVG encodé en URL dans url() plutôt qu'en Base64 — il reste plus petit et se compresse mieux en gzip. Le Base64 pour le SVG n'a de sens que lorsqu'une URI stricte est requise et que l'encodage en pourcentage n'est pas une option.

Il n'y a aucune limite dans la spécification HTML ou CSS, et les navigateurs modernes gèrent des URI de données de plusieurs mégaoctets dans les attributs src. Les plafonds pratiques sont ailleurs : les barres d'adresse coupent généralement autour de 2 Mo ou moins, certaines configurations de serveur et de CDN plafonnent la taille des en-têtes et des requêtes, et les chaînes très longues ralentissent notablement l'analyse. Cet outil n'impose aucun plafond propre, mais il avertit au-delà de 100 Ko car c'est le seuil où l'intégration cesse d'être rentable.

Non. Le fichier est lu avec l'API FileReader du navigateur, qui opère sur le descripteur de fichier local, et la chaîne résultante reste dans la mémoire de la page. Rien n'est envoyé sur le réseau et il n'y a aucun composant côté serveur, si bien que l'outil continue de fonctionner hors ligne une fois la page chargée. Les copies dans le presse-papiers passent par le presse-papiers standard du navigateur, pas par nous.

Tous, pour les images — les URI de données dans les attributs src d'img et les url() CSS fonctionnent depuis IE8 et sont universellement prises en charge aujourd'hui. Le presse-papiers est la partie plus récente : navigator.clipboard nécessite un contexte sécurisé, donc en HTTP simple ou dans les navigateurs plus anciens, cette page se rabat sur la sélection du textarea et l'utilisation de document.execCommand('copy'). Si les deux méthodes échouent, un message vous demandera de sélectionner et copier le texte vous-même.