Décodeur d'image Base64, gratuit
Collez une chaîne Base64 pour prévisualiser et télécharger l'image.
Comment utiliser
- Collez une chaîne d'image encodée en Base64 dans la zone de saisie. Elle peut inclure le préfixe
data:image/…ou contenir uniquement les données Base64 brutes. - Cliquez sur Décoder l'image pour la prévisualiser.
- Cliquez sur Télécharger l'image pour l'enregistrer en fichier PNG.
Questions fréquentes
Quels formats Base64 sont pris en charge ?
Vous pouvez coller une chaîne Base64 brute (l'outil détecte le format automatiquement) ou un URI de données complet comme data:image/png;base64,iVBOR…. Types d'image pris en charge : PNG, JPEG, WebP, GIF, BMP et SVG.
Y a-t-il une limite de taille ?
Il n'y a pas de limite stricte, mais les chaînes Base64 très volumineuses (plus de 5–10 Mo) peuvent être longues à traiter selon votre appareil.
Comment encoder une image en Base64 ?
Utilisez notre outil Convertisseur image → Base64, gratuit · glissez-déposez simplement une image pour obtenir sa chaîne Base64.
Ce qu'est réellement le Base64
Le Base64 est un schéma d'encodage binaire-vers-texte défini dans la RFC 4648 (octobre 2006). Il utilise un alphabet de 64 caractères, A-Z, a-z, 0-9, plus + et / : pour représenter des octets arbitraires en ASCII imprimable. Trois octets d'entrée binaire deviennent exactement quatre caractères de sortie, car le plus petit commun multiple de 6 bits (un caractère Base64) et de 8 bits (un octet) est 24. Ce rapport de quatre pour trois explique aussi pourquoi un fichier encodé en Base64 est environ 33 % plus volumineux que le binaire d'origine.
Lorsque la longueur de l'entrée n'est pas un multiple de trois, le Base64 complète avec = pour que la sortie soit toujours un multiple de quatre caractères : un octet final produit deux caractères plus == ; deux octets finaux produisent trois caractères plus =. Certains encodeurs suppriment le remplissage, de sorte qu'un décodeur robuste doit recompléter avant de passer la chaîne à atob().
La RFC 4648 définit aussi une variante adaptée aux URL (parfois appelée base64url) qui remplace + par - et / par _. Les JWT l'utilisent. Ce décodeur normalise les deux alphabets pour que vous n'ayez pas à vous soucier de celui qu'on vous a remis.
Le schéma d'URI de données
La RFC 2397 (août 1998) définit le schéma d'URL data:. La grammaire complète est :
data:[<mediatype>][;base64],<data>Un PNG en ligne typique ressemble à data:image/png;base64,iVBORw0KGgo…. Le jeton ;base64 est un marqueur (notez l'absence de signe =) qui indique au navigateur de décoder la charge utile depuis le Base64 au lieu de la traiter comme du texte en encodage pour cent. Si vous omettez ;base64, les données sont interprétées comme du texte encodé pour URL. Si vous omettez entièrement le type de média, la spécification utilise text/plain;charset=US-ASCII par défaut.
Ce décodeur accepte les deux formes : collez un URI de données complet ou seulement la charge utile Base64. Lorsque seule la charge utile est fournie, le format est détecté à partir des premiers octets décodés, voir ci-dessous.
Comment le format est détecté
Si vous collez une chaîne Base64 brute sans préfixe data:image/…, le seul moyen de savoir de quel type d'image il s'agit est d'examiner les premiers octets décodés : chaque format d'image courant commence par une signature reconnaissable, formellement appelée « nombre magique ». Les navigateurs effectuent exactement la même vérification lorsqu'ils reniflent les types MIME (la procédure figure dans la norme WHATWG MIME Sniffing). L'astuce, c'est que ces signatures se traduisent par des préfixes Base64 prévisibles :
| Format | Premiers octets (hex) | Préfixe Base64 |
|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | iVBORw0KGgo |
| JPEG | FF D8 FF | /9j/ |
| GIF89a | 47 49 46 38 39 61 | R0lGODlh |
| WebP | 52 49 46 46 … 57 45 42 50 | UklGR |
| BMP | 42 4D (« BM ») | Qk |
| SVG (texte XML) | commence par <?xml ou <svg | PD94bWwg ou PHN2Zw |
La signature du PNG est l'une des plus astucieuses du zoo des formats. L'octet 89 a son bit de poids fort activé, de sorte qu'un relais de courrier limité à 7 bits le corrompt de façon visible. Les trois octets suivants épellent PNG en ASCII, de sorte qu'un humain exécutant head sur le fichier peut le reconnaître. Viennent ensuite une fin de ligne DOS (0D 0A), un Ctrl-Z de MS-DOS qui empêche l'ancienne commande TYPE d'afficher la suite, et un saut de ligne Unix (0A) : ensemble, ils détectent tous les transports courants qui réécrivent « obligeamment » les fins de ligne.
D'où viennent les images Base64
La plupart des gens qui atterrissent sur un outil comme celui-ci sont en train de déboguer quelque chose. Situations courantes :
- Réponses d'API JSON. JSON n'a pas de type binaire natif, de sorte que les API transmettent les images, les PDF signés, les photos de profil et les captures d'écran téléversées sous forme de chaînes Base64 dans des champs JSON. Coller la valeur ici vous permet de voir ce que c'était réellement.
- CSS et ressources empaquetées. Webpack et Vite ont un seuil de petites ressources (Vite utilise 4 Ko par défaut) qui intègre automatiquement les petites images sous forme d'URI de données dans le CSS ou le JS empaqueté. Lorsque vous cherchez « d'où vient cette icône ? », l'URI de données arrive ici.
- Signatures d'e-mail HTML. Gmail, Outlook et Apple Mail intègrent les images de signature sous forme d'URI de données pour que l'image survive au transfert. Les designers ont parfois besoin de récupérer le logo d'origine.
- Exports de CMS et de Notion. Les exports XML de WordPress, les exports de Notion et les sauvegardes Confluence intègrent les vignettes en ligne sous forme de Base64 pour que l'export reste autonome.
- QR codes et pavés de signature. Les bibliothèques de navigateur qui génèrent des QR codes (qrcode.js) ou capturent des signatures manuscrites (signature_pad) exposent généralement leur sortie sous forme de chaîne
data:image/png;base64,…. - Génération de PDF côté serveur. Des outils comme Puppeteer, openhtmltopdf et iText acceptent du HTML avec des URI de données en ligne. Lorsqu'un logo « n'apparaît pas » dans le PDF rendu, décoder l'URI est le moyen le plus rapide de voir si les octets étaient bien une image.
Faut-il intégrer les images en Base64 ?
Le compromis était autrefois plus intéressant. Sous HTTP/1.1, chaque image était une requête bloquante distincte, et intégrer une petite icône pouvait économiser un véritable aller-retour. Sous HTTP/2 et HTTP/3, l'intérêt s'est fortement réduit. Résumé honnête :
Ce que vous gagnez : zéro requête HTTP supplémentaire, une livraison atomique, et des artefacts autonomes qui fonctionnent sans dépendances externes (démos en un seul fichier, e-mail, PDF rendus côté serveur).
Ce que vous perdez : le navigateur ne peut pas mettre en cache un URI de données intégré séparément, de sorte que la même image sur dix pages est retéléchargée à chaque réponse HTML. La ressource encodée est environ 33 % plus volumineuse que l'équivalent binaire. Les CDN ne peuvent pas dédupliquer les images intégrées sur plusieurs pages. Les pipelines d'optimisation d'image (Cloudinary, Vercel, <Image> de Next.js) ne peuvent pas inspecter, compresser, redimensionner ni servir des formats modernes comme AVIF ou WebP pour les ressources intégrées. Le navigateur doit aussi décoder d'abord le Base64 puis l'image, ce qui représente un surcoût de CPU à chaque rendu.
Règles empiriques raisonnables : intégrez les images de moins de 4 Ko environ utilisées à un seul endroit, les placeholders d'un seul pixel, et les images qui doivent voyager à l'intérieur d'un fichier autonome. N'intégrez rien qui soit utilisé sur plus d'une page, rien de plus grand qu'environ 4 Ko, rien qui devrait être chargé en différé, ni rien qui bénéficie d'une négociation de format.
Sécurité : ce que le Base64 ne fait pas
Le Base64 est un encodage, pas un chiffrement. La RFC 4648 § 12 avertit explicitement qu'il « masque visuellement » les données mais n'offre « aucune confidentialité informatique » : n'importe qui peut le décoder instantanément. N'encodez pas en Base64 des mots de passe ou des clés d'API en pensant que c'est une mesure de sécurité.
Deux détails de sécurité à connaître :
- La navigation de premier niveau vers les URL
data:est bloquée dans les navigateurs modernes (en ouvrir une dans un nouvel onglet ne fonctionne pas) pour atténuer les attaques de phishing qui affichaient de fausses pages de connexion à partir d'URI de données. L'utilisation en sous-ressource (<img src="data:…">,url(data:…)en CSS) reste autorisée. - Le SVG est un cas à part. Le SVG est du XML, et les documents SVG peuvent contenir des éléments
<script>et des gestionnaires d'événements. Charger un SVG dans une balise<img>est sûr (les navigateurs exécutent un moteur de rendu avec les scripts désactivés), mais charger le même SVG dans<object>ou<iframe>peut exécuter du JavaScript arbitraire. Ce décodeur ne définit jamais que<img src>, ce qui est la voie sûre. Si vous avez décodé un SVG provenant d'une source non fiable, traitez le fichier comme n'importe quel autre document non fiable.
Autres questions
Pourquoi ma chaîne Base64 échoue-t-elle avec « InvalidCharacterError » ?
Trois causes habituelles : des espaces ou des sauts de ligne parasites issus d'un copier-coller (l'ancien profil MIME Base64 coupe les lignes à 76 caractères, ce que atob() de JavaScript rejette) ; du Base64 adapté aux URL avec - et _ au lieu de + et / ; ou un remplissage = final supprimé, de sorte que la longueur n'est pas un multiple de quatre. Ce décodeur nettoie les espaces, normalise l'alphabet et recomplète avant de décoder, mais les chaînes très corrompues échouent quand même.
Est-ce que je perds en qualité lors du décodage ?
Non. Le décodage est l'inverse exact de l'encodage : vous récupérez l'image d'origine octet par octet. Le téléchargement se fait dans le format qui était dans le Base64 (PNG, JPEG, WebP, GIF, BMP ou SVG), sans étape de réencodage.
Quel est le plus grand URI de données qu'un navigateur acceptera ?
D'après MDN, les limites actuelles sont d'environ 512 Mo pour Chromium et Firefox, et d'environ 2 Go pour Safari/WebKit. En pratique, le goulot d'étranglement est la mémoire et le CPU plutôt que la spécification d'URL : les collages au-dessus d'environ 10 Mo commencent à paraître lents sur un ordinateur portable typique.
Des données sont-elles envoyées à un serveur ?
Non. Le décodage se produit entièrement dans votre navigateur via la fonction native atob() et un Blob ou un URI de données affecté à une balise <img>. Rien n'est téléversé ; la page fonctionne hors ligne une fois chargée.
Pourquoi le Base64 de chaque JPEG commence-t-il par /9j/ ?
Presque tous les fichiers JPEG dans la nature commencent par les octets FF D8 FF (marqueur Start-Of-Image suivi d'un autre octet de marqueur). Lorsque vous encodez en Base64 trois octets qui sont tous FF avec un D8 au milieu, le motif de bits 11111111 11011000 11111111 se découpe en groupes de 6 bits 111111 111101 100011 111111 : les positions 63, 61, 35, 63 de l'alphabet Base64, qui épellent /9j/. Le quatrième caractère varie ensuite selon le marqueur qui suit (E0 pour JFIF, E1 pour Exif), mais les trois premiers sont universels.