Quando converti un’immagine in Base64, ottieni un data URI: una stringa come data:image/png;base64,iVBORw0KGgo… che puoi incollare direttamente in un attributo src HTML o in un url() CSS. Il browser la decodifica al volo e mostra l’immagine senza alcun download separato. Nessun file da ospitare, nessuna richiesta extra.
Quindi conviene farlo? La regola breve è questa. Incorpora un’immagine come Base64 quando è piccola (sotto i 2 KB circa), cambia raramente e vuoi risparmiare una richiesta HTTP: pensa a piccole icone e loghi. Per tutto il resto, cioè immagini grandi, qualsiasi cosa riutilizzata su più pagine o che vuoi far mettere in cache dal browser, tienila come un normale file immagine. Il problema è che il Base64 rende un file circa il 33% più grande, e una volta che quel testo è incorporato nel tuo HTML o CSS non può più essere messo in cache per conto suo.
Se vuoi i numeri esatti per un file specifico, il convertitore Immagine in Base64 esegue la codifica nel tuo browser e mostra l’aumento di dimensione preciso, così decidi con dati reali invece che con una regola generica. Questa guida spiega cos’è davvero quel data URI, la matematica dietro la tassa sulla dimensione, quando l’incorporamento conviene e i casi in cui un semplice file vince.
Cosa produce davvero “immagine in Base64”: il data URI
Convertire un’immagine in Base64 non ti dà un file. Ti dà una lunga stringa che segue il formato data URI definito nell’RFC 2397 (vedi il riferimento agli URL data: di MDN). La stringa ha tre parti:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytesIl tipo MIME dice al browser che genere di immagine sta decodificando. I più comuni per le immagini sono image/png, image/jpeg, image/gif, image/webp, image/svg+xml e image/x-icon per le favicon. Il marcatore ;base64, indica che il contenuto che segue è in Base64 anziché testo semplice. Tutto ciò che viene dopo la virgola è l’immagine, riespressa come ASCII stampabile.
Quest’ultima parte conta per la privacy. La conversione avviene interamente nel tuo browser tramite il metodo readAsDataURL dell’API FileReader: nulla viene caricato su un server. Puoi trascinare uno screenshot pre-lancio, un diagramma interno o un’opera grafica non ancora pubblicata nello strumento e vedere la scheda Network restare vuota. Per capire come i byte grezzi diventano quella stringa ASCII, capire il Base64 spiega la codifica dalle fondamenta, e la guida completa al Base64 estende la stessa idea di data URL a font, PDF e altri tipi di file.
Un esempio reale: un PNG trasparente da 68 byte
Ecco il caso pratico più piccolo possibile: un PNG trasparente 1×1, 68 byte su disco, come data URI completo:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==Incolla questo nella barra degli indirizzi di un browser e vedrai (be’, non vedrai, perché è trasparente) un’immagine valida che si carica con zero attività di rete. Nota i == finali: è il padding, di cui parliamo a breve. Questo è anche esattamente l’aspetto del Base64 testuale, solo applicato a byte di immagine invece che a testo. Se devi solo codificare o decodificare semplici stringhe di testo, lo strumento codifica/decodifica Base64 gestisce quel caso.
La tassa del 33% sulla dimensione (e perché si somma)
Il Base64 lavora in gruppi fissi: ogni 3 byte di binario diventano 4 caratteri ASCII. Quattro terzi è circa 1.33, da cui deriva la cifra del +33%. Aggiungi un byte o due di padding più il prefisso data:image/png;base64, e l’overhead sale un po’ per i file minuscoli. Un esempio concreto: un PNG da 9 KB diventa circa 12 KB di testo.
Perché esattamente 3 a 4? Il Base64 usa un alfabeto di 64 caratteri: A–Z, a–z, 0–9, più + e /. Sessantaquattro simboli sono 6 bit di informazione per carattere. I byte binari sono 8 bit ciascuno. Il minimo comune multiplo di 6 e 8 è 24 bit, cioè 3 byte o 4 caratteri Base64, quindi il codificatore avanza nell’immagine 24 bit alla volta. Quando la lunghezza dell’immagine non è un multiplo netto di 3, uno o due caratteri = riempiono l’ultimo gruppo. Questa è la matematica, ed è fissa: non esiste un’impostazione del codificatore che riduca il 33%.
Quel 33% è il costo visibile. Il costo nascosto è che si somma, ed è la parte che la maggior parte dei consigli del tipo “incorporala e basta” tralascia:
- L’immagine viene riscaricata ogni volta che cambia il file che la contiene. Un
logo.pngesterno è una risorsa a sé. Incorporalo instyles.csse ora ogni modifica a quel foglio di stile, anche solo un ritocco di colore o una nuova regola, invalida pure la cache dell’immagine. I visitatori riscaricano l’immagine che già avevano. - Non può essere messa in cache in modo indipendente. Un normale file immagine viene scaricato una volta e riutilizzato su ogni pagina e a ogni visita. Un data URI incorporato fa parte del documento, quindi viene rispedito su ogni pagina che lo include e a ogni cache miss di quel documento.
- Il CSS blocca il rendering. Il browser non disegna nulla finché non ha il CSS. Infila un grande data URI in un foglio di stile e avrai reso più grande una risorsa che blocca il rendering, ritardando il primo paint dell’intera pagina.
gzip o brotli annullano il 33%?
In parte, non del tutto. Il testo Base64 è abbastanza ripetitivo da farsi comprimere bene da gzip e brotli, recuperando una buona fetta dell’inflazione sul filo. Ma due cose restano vere. Primo, il Base64 compresso è di solito ancora un po’ più grande del binario originale compresso, perché hai dato al compressore un punto di partenza meno efficiente. Secondo, e qui sta il punto più importante, la compressione non fa nulla riguardo alla cache o al blocco del rendering. Un data URI più piccolo sul filo viene comunque riscaricato con il suo file ospite e comunque non può essere messo in cache per conto suo.
In altre parole, la compressione non equivale a eliminare il costo dell’incorporamento. Se la distinzione tra minificare, comprimere con gzip e brotli è confusa, la guida alla minificazione del codice spiega come questi livelli si sovrappongono, e perché spremere i byte non risolve mai il problema della cache che l’incorporamento crea.
Quando usare un’immagine Base64 (la matrice decisionale)
L’intera decisione si riduce a una manciata di fattori, messi qui a confronto:
| Fattore | Propendi per l’incorporamento (Base64) | Propendi per un file normale |
|---|---|---|
| Dimensione | Sotto i ~2 KB (verde) | Sopra i ~10 KB (rosso); 2–10 KB è una scelta caso per caso (giallo) |
| Riutilizzo | Una pagina, un posto o due | Ripetuta su molte pagine |
| Frequenza di modifica | Non cambia quasi mai | Modificata spesso |
| Contesto | Email HTML, widget o bookmarklet autonomo, payload JSON/API, un’icona critica above-the-fold che vale una richiesta risparmiata | Immagini di contenuto, asset condivisi e cacheabili |
Quelle soglie di dimensione non sono arbitrarie: rispecchiano il badge a semaforo integrato nel convertitore Immagine in Base64: verde sotto i 2 KB, giallo fino a 10 KB, rosso oltre. Lo strumento legge il tuo file reale e ti dice in quale fascia ricade.
Una semplice regola pratica
Se ricordi una sola riga, sia questa: sotto i ~2 KB e usata in uno o due posti soltanto, l’incorporamento di solito conviene; sopra i ~10 KB o riutilizzata su più pagine, un normale file in cache vince quasi sempre. La fascia intermedia 2–10 KB è dove soppesi la richiesta risparmiata contro la cache persa per la tua situazione specifica.
I casi adatti nel dettaglio
Alcuni casi in cui il Base64 ha davvero senso:
- Email HTML. Molti client di posta bloccano per impostazione predefinita le immagini ospitate esternamente per motivi di privacy, il che rompe qualsiasi layout che dipenda da un logo remoto. Un piccolo data URI incorporato si carica subito senza fetch dal server. Limitati a loghi e icone; non incorporare mai una fotografia in un’email.
- Widget e bookmarklet autonomi. Un bookmarklet o un widget incorporabile deve funzionare con zero dipendenze esterne. Incorporare le sue icone tiene tutto in un unico file trascinabile.
- Payload JSON e API. Spedire una miniatura dentro un documento JSON o un file di configurazione è a volte l’opzione più pulita: un solo round trip, un solo oggetto, nessuna seconda richiesta da predisporre.
- Un’icona critica above-the-fold. Quando un piccolo logo fa parte del tuo Largest Contentful Paint e vuoi togliere una richiesta dal percorso critico, l’incorporamento può aiutare. L’enfasi è su piccolo.
Questi casi hanno un tratto in comune: in ognuno l’asset viaggia insieme a qualcos’altro e altrimenti avrebbe bisogno di un proprio canale di consegna. Un’email non può contare sulla tua CDN. Un bookmarklet non ha un secondo file da scaricare. Una risposta JSON è un payload unico. In ciascun caso, l’alternativa all’incorporamento non è “un file in cache” ma “un’immagine mancante”, il che cambia del tutto il calcolo. La domanda da farsi per un buon caso d’uso del Base64 non è solo “è piccola?”, ma “un file separato è anche solo un’opzione qui?”.
Quando NON incorporare: cache, lazy loading e Core Web Vitals
L’altra faccia della medaglia è più lunga, perché l’incorporamento disattiva silenziosamente diverse cose che il browser fa bene.
Prima cosa, perdi la cache indipendente, e questo pesa soprattutto sui visitatori di ritorno. Una normale immagine resta nella loro cache dopo la prima visita e si carica all’istante per sempre. Un’immagine incorporata non ha una voce di cache propria: viaggia insieme al documento ogni singola volta, quindi un visitatore di ritorno paga di nuovo il costo in byte, ancora e ancora.
Perdi anche il lazy loading. L’attributo loading="lazy" permette al browser di rinviare le immagini sotto la piega finché l’utente non scorre vicino a esse. Un data URI viene analizzato e “scaricato” nell’istante in cui l’HTML viene letto, quindi non c’è nulla da rinviare. Incorpora una dozzina di immagini sotto la piega e le avrai forzate tutte nel caricamento iniziale.
E ingrandisci le risorse che bloccano il rendering. Come detto prima, un data URI dentro il CSS gonfia una risorsa che blocca il primo paint. Più grande è quel foglio di stile, più a lungo la pagina resta bianca.
Decodificare costa di più su mobile. Un data URI viene decodificato da Base64 a ogni caricamento del suo documento, e sui telefoni di fascia bassa quel lavoro di CPU si accumula; per di più i byte non finiscono mai nella cache su disco del browser, quindi un’immagine pesante incorporata viene ridecodificata a ogni visita, invece di essere messa in cache e decodificata una sola volta come un file normale.
C’è anche un motivo storico per cui questo consiglio è cambiato. La tesi originale a favore dell’incorporamento, sostenuta a gran voce nell’era di HTTP/1.1, era la riduzione delle richieste: ogni connessione poteva scaricare una risorsa alla volta, quindi una pagina con 40 piccole icone pagava 40 round trip. HTTP/2 ha cambiato le cose multiplexando molte richieste su una singola connessione, il che ha reso economici i piccoli file extra. Il grande vantaggio dell’incorporamento, cioè meno richieste, è in gran parte evaporato, mentre i costi (cache persa, niente lazy loading, file che bloccano il rendering più grandi) sono rimasti. Se leggi articoli più vecchi entusiasti degli sprite Base64, valutali rispetto al protocollo su cui il tuo sito gira davvero oggi.
Il versante Core Web Vitals
L’incorporamento taglia in entrambe le direzioni sull’LCP (Largest Contentful Paint). Per una piccola immagine above-the-fold che è l’elemento LCP, rimuovere una richiesta può anticipare l’LCP di un soffio. Ma incorpora un’immagine grande e fai l’opposto: ritardi il documento o il foglio di stile in cui vive, spostando l’LCP più in là per l’intera pagina. La soglia di dimensione decide in quale direzione va.
Per il CLS (Cumulative Layout Shift), l’incorporamento non cambia nulla riguardo alla regola di base: un’immagine ha comunque bisogno di width e height espliciti (o di un box con aspect-ratio) così che il browser possa riservare lo spazio prima di renderizzarla. Un data URI senza dimensioni sposta il layout esattamente come un’immagine remota senza dimensioni.
Spesso la leva migliore non è l’incorporamento ma ridurre la sorgente. Comprimere un’immagine prima di codificarla rende più piccoli sia il file sia qualsiasi data URI risultante: la guida alla compressione delle immagini browser vs Node spiega come farlo lato client o in uno step di build, e WebP vs AVIF vs JPEG ti aiuta a scegliere un formato che è piccolo già in partenza.
Come incorporare immagini in HTML, CSS, Markdown e JSON
Una volta che hai un data URI, si inserisce in ogni contesto in modo diverso. Sono i quattro snippet pronti da incollare che il convertitore Immagine in Base64 genera per te.
HTML: incolla l’URI in qualsiasi src.
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…" alt="logo">CSS: avvolgilo in url() per un background-image (è lo schema canonico immagine base64 in CSS).
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}Markdown: un link a immagine autonomo per README, issue di GitHub e notebook dove non puoi ospitare un file.
JSON: un asset incorporato dentro un payload API o di configurazione.
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }Tutti e quattro funzionano ovunque sia accettato un URL: img src, background CSS, mask-image, perfino un <link> favicon. Ogni browser moderno supporta lo schema data:.
Generarli rapidamente
Costruirli a mano è soggetto a errori: un tipo MIME sbagliato o un’interruzione di riga vagante e l’immagine non si carica senza dare segnali. Trascina il tuo file nel convertitore Immagine in Base64 e produce tutti e quattro gli snippet con i loro pulsanti di copia dedicati, oltre all’aumento di dimensione esatto così sai in anticipo se l’asset merita di stare inline.
SVG: il caso speciale in cui il Base64 di solito perde
L’SVG rompe la logica consueta, perché l’SVG è testo, non binario. Il Base64 esiste per rendere i dati binari sicuri come testo, ma l’SVG è già testo XML. Codificarlo come Base64 non fa che gonfiare una stringa che non aveva bisogno di codifica, e nel processo la rende illeggibile. Quindi per l’SVG nello specifico, il Base64 è quasi sempre la scelta sbagliata.
Confronta tre modi di incorporare la stessa icona:
/* 1. Data URI Base64 — aggiunge la tassa del 33% a testo che non ne aveva bisogno */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. Data URI con URL-encoding — codifica in percentuale pochi caratteri, niente tassa del 33% */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. <svg> inline direttamente nell'HTML — completamente personalizzabile con i CSS */<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
<path d="M12 2 L22 22 H2 Z" fill="currentColor" />
</svg>L’opzione 2 (URL-encoding) è di solito più piccola dell’opzione 1, resta leggibile e si comprime meglio. Codifichi in percentuale solo i caratteri che romperebbero l’URI, cioè <, >, # e le virgolette, lasciando leggibile il resto. L’approccio dell’encoder/decoder URL è documentato nello strumento stesso; ricorri all’SVG Base64 solo quando una pipeline di build lo richiede espressamente.
Perché un <svg> inline spesso batte un’icona PNG in Base64
Se devi scegliere tra un’icona PNG codificata in Base64 e un <svg> inline, l’SVG di solito vince su ogni fronte. Si adatta a qualsiasi dimensione senza sfocarsi, non porta la tassa del 33% e, a differenza di qualsiasi data URI, puoi personalizzarlo con i CSS, animarlo e ricolorarlo con currentColor. Un PNG in Base64 è un blob a risoluzione fissa che non puoi toccare una volta codificato. Riserva il Base64 raster ai casi in cui ti serve davvero una fotografia o uno screenshot raster inline.
Decodificare nell’altro senso: dal Base64 all’immagine
Il problema inverso è altrettanto comune: hai una stringa Base64, estratta da una risposta API, da una riga di log, da una colonna di database o da un foglio di stile che stai debuggando, e devi vedere l’immagine reale.
Due dettagli mettono in difficoltà. Primo, la differenza tra Base64 grezzo e data URI completo. Un data URI completo (data:image/png;base64,…) porta con sé il proprio tipo MIME; un payload nudo (iVBORw0KGgo…) no. Per renderizzare un payload nudo o anteponi un prefisso data: corretto oppure lasci che uno strumento deduca il formato dai byte iniziali: iVBORw0KGgo significa PNG, /9j/ significa JPEG, R0lGOD significa GIF.
Secondo, l’interruzione di riga. Il Base64 proveniente da email o da tooling più vecchio è spesso spezzato a 76 caratteri secondo l’RFC 2045. Quegli a capo vanno rimossi prima di decodificare, altrimenti la stringa è invalida in un attributo HTML o in un url().
Nel browser puoi passare un data URI completo direttamente a un <img>:
<img src="data:image/png;base64,iVBORw0KGgo…" alt="decoded">Sul server, Node ricostruisce il file dal payload:
import { writeFileSync } from "node:fs";
const b64 = "iVBORw0KGgoAAAANSUhEUgAA…"; // payload grezzo, senza prefisso data:
writeFileSync("output.png", Buffer.from(b64, "base64"));Per un percorso no-code usa il convertitore Base64 in immagine: incolli una stringa (con o senza prefisso, a capo inclusi), la visualizzi in anteprima, leggi dimensioni e tipo MIME, e scarichi un vero PNG, JPG, GIF o SVG. Lo strumento rimuove gli spazi bianchi, tollera un prefisso mancante e rileva automaticamente il formato dai magic byte.
Un controllo che vale la pena fare su un’immagine decodificata: guarda le dimensioni riportate. Se hai estratto una stringa da un file che ne conteneva diverse e il risultato è 1×1, probabilmente hai preso un pixel di tracciamento invece dell’asset che volevi. E ricorda che la decodifica è puramente meccanica e senza perdite: un PNG in Base64 torna come l’identico PNG, byte per byte, senza ricompressione. L’unica cosa cambiata lungo il percorso era il contenitore: una stringa di testo all’andata, un file binario al ritorno.
FAQ
Dovrei convertire le mie immagini in Base64?
Solo quando ne vale la pena: icone o loghi piccoli (sotto i ~2 KB), che cambiano raramente, dove risparmiare una richiesta HTTP conta, più email HTML, widget autonomi e payload JSON. Le immagini grandi o qualsiasi cosa riutilizzata su più pagine dovrebbero quasi sempre restare file normali, così mantieni cache e lazy loading.
Quanto rende più grande un’immagine il Base64?
Circa il +33%. Il Base64 codifica ogni 3 byte di binario come 4 caratteri ASCII, più un po’ di padding e il prefisso data:. Un PNG da 9 KB diventa circa 12 KB di testo. Per convertire un’immagine in Base64 e vedere l’aumento esatto per il tuo file, lo strumento riporta il numero preciso nella sua barra dei metadati.
Il Base64 fa caricare le immagini più velocemente?
Per un’icona above-the-fold molto piccola può farlo, risparmiando il round trip di una richiesta. Per immagini più grandi o riutilizzate è di solito più lento: perdi la cache indipendente, non puoi caricarla in lazy e incorporarla nel CSS ingrandisce una risorsa che blocca il rendering. La dimensione è il fattore decisivo.
Posso usare un’immagine Base64 nel CSS?
Sì: background-image: url("data:image/png;base64,…"). Va bene per icone minuscole. Ricorda solo che il data URI diventa parte del foglio di stile, quindi l’intero file viene riscaricato ogni volta che il CSS cambia, e l’immagine non può essere messa in cache separatamente da esso.
Dovrei usare SVG o Base64 per le icone?
Preferisci un <svg> inline o un data URI SVG con URL-encoding. L’SVG è testo, si adatta in modo pulito e non porta la tassa del 33%, quindi è di solito più piccolo di un PNG in Base64 e puoi personalizzarlo con i CSS. Ricorri al Base64 solo quando ti serve specificamente un’icona raster.
Come riconverto una stringa Base64 in un’immagine?
Nel browser, trascina un URI completo data:image/…;base64,… in un <img src>. Su un server, usa Buffer.from(b64, "base64") per scrivere il file. Un payload grezzo ha bisogno che gli venga aggiunto un prefisso data:, e le stringhe spezzate su più righe hanno bisogno che gli a capo vengano rimossi prima. Lo strumento Base64 in immagine gestisce tutto questo e ti permette di scaricare il risultato.