Stringa Base64 o Data URI

Come usare

1. Incolla una stringa di immagine codificata in Base64 nella casella di input. Può includere il prefisso data:image/… o contenere solo i dati Base64 grezzi.
2. Clicca su Decodifica l'immagine per visualizzarne l'anteprima.
3. Clicca su Scarica l'immagine per salvarla come file PNG.

Domande frequenti

Quali formati Base64 sono supportati?

Puoi incollare una stringa Base64 grezza (lo strumento rileva il formato automaticamente) o un Data URI completo come data:image/png;base64,iVBOR…. Tipi di immagine supportati: PNG, JPEG, WebP, GIF, BMP e SVG.

C'è un limite di dimensione?

Non c'è un limite rigoroso, ma stringhe Base64 molto grandi (oltre 5–10 MB) possono essere lente da elaborare a seconda del tuo dispositivo.

Come faccio a codificare un'immagine in Base64?

Usa il nostro Convertitore da immagine a base64 · trascina e rilascia un'immagine per ottenerne la stringa Base64.

Cos'è davvero Base64

Base64 è uno schema di codifica da binario a testo definito nella RFC 4648 (ottobre 2006). Utilizza un alfabeto di 64 caratteri, A-Z, a-z, 0-9, più + e /, per rappresentare byte arbitrari come ASCII stampabile. Ogni tre byte di input binario diventano esattamente quattro caratteri di output, perché il minimo comune multiplo di 6 bit (un carattere Base64) e 8 bit (un byte) è 24. Questo rapporto quattro-a-tre è anche il motivo per cui un file codificato in Base64 è circa il 33% più grande del binario originale.

Quando la lunghezza dell'input non è un multiplo di tre, Base64 aggiunge padding con = in modo che l'output sia sempre un multiplo di quattro caratteri: un byte finale produce due caratteri più ==; due byte finali producono tre caratteri più =. Alcuni encoder eliminano il padding, quindi un decoder robusto deve aggiungere nuovamente il padding prima di passare la stringa a atob().

RFC 4648 definisce anche una variante URL-safe (a volte chiamata base64url) che sostituisce + con - e / con _. I JWT la usano. Questo decoder normalizza entrambi gli alfabeti così non è necessario preoccuparsi di quale si ha tra le mani.

Lo schema URI dati

RFC 2397 (agosto 1998) definisce lo schema URL data:. La grammatica completa è:

data:[<mediatype>][;base64],<data>

Un PNG inline tipico ha l'aspetto data:image/png;base64,iVBORw0KGgo…. Il token ;base64 è un marcatore (notare l'assenza del segno =) che indica al browser di decodificare il payload da Base64 anziché trattarlo come testo con codifica percentuale. Se si omette ;base64, i dati vengono interpretati come testo con codifica URL. Se si omette del tutto il media type, la specifica usa come valore predefinito text/plain;charset=US-ASCII.

Questo decoder accetta entrambe le forme: incollare un data URI completo o solo il payload Base64. Quando viene fornito solo il payload, il formato viene rilevato dai primi byte decodificati; vedere di seguito.

Come viene rilevato il formato

Se si incolla una stringa Base64 grezza senza il prefisso data:image/…, l'unico modo per sapere che tipo di immagine sia è guardare i primi byte decodificati; ogni formato di immagine comune inizia con una firma riconoscibile, formalmente chiamata «numero magico». I browser eseguono esattamente lo stesso controllo durante lo sniffing dei tipi MIME (la procedura è nello standard WHATWG MIME Sniffing). Il punto è che quelle firme si traducono in prefissi Base64 prevedibili:

Formato	Primi byte (hex)	Prefisso 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 (testo XML)	inizia con <?xml o <svg	PD94bWwg o PHN2Zw

La firma PNG è una delle più intelligenti nel panorama dei formati. Il byte 89 ha il bit più significativo impostato in modo che un relay di posta a soli 7 bit lo corrompa visibilmente. I tre byte successivi compongono PNG in ASCII, così un essere umano che esegue head sul file può riconoscerlo. Poi arrivano un terminatore di riga DOS (0D 0A), un Ctrl-Z di MS-DOS che impedisce al comando legacy TYPE di continuare la stampa, e un avanzamento di riga Unix (0A); insieme rilevano ogni comune sistema di trasporto che riscrive «utilmente» le terminazioni di riga.

Da dove provengono le immagini Base64

La maggior parte delle persone che arrivano a uno strumento come questo stanno facendo debug di qualcosa. Situazioni comuni:

• Risposte delle API JSON. JSON non ha un tipo binario nativo, quindi le API trasmettono immagini, PDF firmati, foto profilo e screenshot caricati come stringhe Base64 all'interno di campi JSON. Incollare il valore qui permette di vedere cosa fosse realmente.
• CSS e asset raggruppati. Webpack e Vite hanno una soglia per gli asset piccoli (Vite ha 4 KB come valore predefinito) che incorpora automaticamente le immagini piccole come data URI nel CSS o JS raggruppato. Quando si fa debug su «da dove viene questa icona?» il data URI finisce qui.
• Firme e-mail HTML. Gmail, Outlook e Apple Mail incorporano inline le immagini della firma come data URI in modo che l'immagine sopravviva all'inoltro. I designer a volte hanno bisogno di recuperare il logo originale.
• Export di CMS e Notion. Gli export XML di WordPress, gli export di Notion e i backup di Confluence incorporano inline le miniature come Base64 per mantenere l'export autonomo.
• Codici QR e pad di firma. Le librerie browser che generano codici QR (qrcode.js) o acquisiscono firme scritte a mano (signature_pad) tipicamente espongono il loro output come stringa data:image/png;base64,….
• Generazione di PDF lato server. Strumenti come Puppeteer, openhtmltopdf e iText accettano HTML con data URI inline. Quando un logo «non appare» nel PDF renderizzato, decodificare l'URI è il modo più rapido per verificare se i byte fossero anche solo un'immagine.

Si dovrebbero incorporare inline le immagini come Base64?

Il compromesso era più interessante in passato. Con HTTP/1.1 ogni immagine era una richiesta bloccante separata e incorporare inline una piccola icona poteva risparmiare un vero round-trip. Con HTTP/2 e HTTP/3 il vantaggio si è ridotto notevolmente. Sintesi onesta:

Si guadagna: zero richieste HTTP aggiuntive, consegna atomica e artefatti autonomi che funzionano senza dipendenze esterne (demo a file singolo, e-mail, PDF renderizzati lato server).

Si perde: il browser non può memorizzare nella cache separatamente un data URI inline, quindi la stessa immagine su dieci pagine viene riscaricata con ogni risposta HTML. L'asset codificato è circa il 33% più grande dell'equivalente binario. I CDN non possono deduplicare le immagini incorporate su più pagine. Le pipeline di ottimizzazione delle immagini (Cloudinary, Vercel, Next.js <Image>) non possono ispezionare, comprimere, ridimensionare o servire formati moderni come AVIF o WebP per gli asset inline. Il browser deve anche decodificare prima il Base64 e poi l'immagine, con un costo CPU aggiuntivo a ogni render.

Regole pratiche ragionevoli: incorporare inline le immagini più piccole di circa 4 KB usate in un solo posto, i segnaposto a pixel singolo e le immagini che devono viaggiare all'interno di un file autonomo. Non incorporare inline nulla che venga usato su più di una pagina, nulla di più grande di circa 4 KB, nulla che debba essere caricato in lazy o nulla che benefici della negoziazione del formato.

Sicurezza: cosa non fa Base64

Base64 è codifica, non cifratura. RFC 4648 §12 avverte esplicitamente che «nasconde visivamente» i dati ma non fornisce «nessuna confidenzialità computazionale»; chiunque può decodificarli istantaneamente. Non codificare in Base64 password o chiavi API pensando che sia una misura di sicurezza.

Due dettagli di sicurezza da conoscere:

• La navigazione di primo livello verso gli URL data: è bloccata nei browser moderni (aprirne uno in una nuova scheda non funzionerà) per mitigare gli attacchi di phishing che renderizzavano pagine di login false da data URI. L'uso come sottorisorsa (<img src="data:…">, CSS url(data:…)) è ancora consentito.
• SVG è speciale. SVG è XML e i documenti SVG possono contenere elementi <script> e gestori di eventi. Caricare un SVG in un tag <img> è sicuro (i browser usano un renderer con script disabilitati), ma caricare lo stesso SVG in <object> o <iframe> può eseguire JavaScript arbitrario. Questo decoder imposta sempre solo <img src>, che è il percorso sicuro. Se si è decodificato un SVG da una fonte non attendibile, trattare il file come qualsiasi altro documento non attendibile.

Altre domande

Perché la mia stringa Base64 fallisce con «InvalidCharacterError»?

Tre cause usuali: spazi bianchi o interruzioni di riga spurie da un copia-incolla (il vecchio profilo MIME Base64 va a capo a 76 caratteri, che JavaScript atob() rifiuta); Base64 URL-safe con - e _ al posto di + e /; oppure il padding = finale eliminato così la lunghezza non è un multiplo di quattro. Questo decoder pulisce gli spazi bianchi, normalizza l'alfabeto e aggiunge nuovamente il padding prima della decodifica, ma le stringhe molto corrotte falliscono comunque.

Si perde qualità durante la decodifica?

No. La decodifica è l'inverso esatto della codifica; si recupera byte per byte l'immagine originale. Il download è nel formato presente nel Base64 (PNG, JPEG, WebP, GIF, BMP o SVG), senza alcuna fase di ri-codifica.

Qual è il data URI più grande che un browser accetterà?

Secondo MDN, i limiti attuali sono circa 512 MB per Chromium e Firefox, e circa 2 GB per Safari/WebKit. In pratica il collo di bottiglia è la memoria e la CPU piuttosto che la specifica URL; i testi incollati superiori a circa 10 MB iniziano a sembrare lenti su un laptop tipico.

Vengono inviati dati a un server?

No. La decodifica avviene interamente nel browser tramite la funzione nativa atob(), un Blob o un data URI assegnato a un tag <img>. Nulla viene caricato; la pagina funziona offline una volta caricata.

Perché il Base64 di ogni JPEG inizia con /9j/?

Quasi ogni file JPEG in circolazione inizia con i byte FF D8 FF (marcatore Start-Of-Image seguito da un altro byte marcatore). Quando si codifica in Base64 una sequenza con FF e D8 nel mezzo, il pattern di bit 11111111 11011000 11111111 si divide in gruppi da 6 bit 111111 111101 100011 111111: posizioni dell'alfabeto Base64 63, 61, 35, 63, che compongono /9j/. Il quarto carattere varia poi in base al marcatore che segue (E0 per JFIF, E1 per Exif), ma i primi tre sono universali.

Strumenti correlati