Convertitore da immagine a base64

Come funziona

1. Trascina o seleziona un'immagine. Il browser legge il file localmente con l'API FileReader. Nulla viene caricato da nessuna parte.
2. Il codificatore converte i byte usando l'alfabeto Base64 standard, ogni 3 byte di input diventano 4 caratteri ASCII presi da A-Z a-z 0-9 + /, con fino a due caratteri di riempimento = finali quando la lunghezza dell'input non è un multiplo di 3.
3. Copia ciò che ti serve. «Copy Base64» ti dà solo la stringa codificata (utile per i payload JSON o l'elaborazione lato backend). «Copy Data URI» ti dà la forma completa data:image/png;base64,… pronta da inserire in un attributo <img src> o in un background-image: url(…) CSS.
4. Incollalo dove deve stare. L'output è testo semplice, funziona in HTML, CSS, JSON, JavaScript, Markdown, o in qualunque altro posto in cui possa vivere una stringa.

Cosa fa davvero Base64

Base64 è definito nella RFC 4648 (ottobre 2006). La codifica prende 24 bit di input alla volta (tre byte) e li riscrive come quattro indici a 6 bit in un alfabeto di 64 caratteri. La matematica è esatta: 3 byte (24 bit) → 4 caratteri (ciascuno che porta 6 bit). Quando la lunghezza dell'input non è un multiplo di 3, il codificatore aggiunge caratteri di riempimento = per rendere la lunghezza dell'output un multiplo di 4.

Due conseguenze pratiche:

• L'output è sempre ~33% più grande dell'input. Il rapporto 4/3 è fondamentale per l'algoritmo. Un'immagine da 100 KB diventa ~133 KB in Base64. Con le interruzioni di riga in stile MIME ogni 76 caratteri il sovraccarico si avvicina al 37%.
• L'output è sicuro come testo ovunque. L'alfabeto di 64 caratteri è l'intersezione di ogni comune canale di testo ASCII, HTML, JSON, XML, e-mail, URL (con la variante sicura per URL), codice sorgente. È l'intera ragione per cui Base64 esiste: spostare dati binari attraverso sistemi progettati per il testo.

La RFC 4648 §12 esplicita una importante non-funzionalità: «la codifica Base64 nasconde visivamente informazioni altrimenti facilmente riconoscibili, come le password, ma non fornisce alcuna riservatezza computazionale.» Chiunque può decodificare una stringa Base64 in due righe di codice in qualsiasi linguaggio. È codifica, non cifratura.

I data URI: la forma a immagine inline

Un «data URI» è il formato contenitore che permette a una stringa Base64 di prendere il posto di un URL di immagine. La RFC 2397 (1998) definisce la sintassi:

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

Per le immagini, ciò significa data:image/png;base64,iVBORw0KGgo… in un attributo <img src> o background-image: url("data:image/svg+xml;utf8,<svg…>") in CSS. Il token ;base64 dice al browser che la parte dati è codificata; senza di esso, i dati vengono presi come testo con codifica percentuale. La stessa RFC 2397 nota che i data URI sono «utili solo per valori brevi», un suggerimento che è invecchiato fino a diventare una rigida regola di prestazioni.

Quando dovresti incorporare un'immagine come Base64

• Artefatti a file singolo. Una firma e-mail con un logo incorporato che deve sopravvivere all'inoltro. Una demo HTML autonoma per CodePen, JSFiddle, o una riproduzione per una segnalazione di bug. Un PDF generato in cui l'immagine deve essere incorporata così che il file funzioni offline.
• Minuscole icone del percorso critico. Un chevron o uno spinner di caricamento da 200 byte incorporato nel CSS critico può caricarsi più velocemente che attivare una richiesta HTTP separata, specialmente su connessioni lente.
• Risposte JSON / API inline. Caricamenti di avatar, firme, campioni OCR, codici QR generati, qualunque cosa in cui il consumatore dell'API si aspetti i byte inline anziché un URL separato da recuperare.
• Iframe in sandbox o altri contesti che vietano il caricamento di risorse esterne.
• File di configurazione dove non vuoi un file immagine affiancato al JSON / TOML / YAML.

Quando non dovresti incorporare un'immagine come Base64

Per la maggior parte dei siti web di produzione, un'immagine Base64 incorporata è più lenta di un normale riferimento <img>. Cinque ragioni che si sommano:

1. 33% di sovraccarico di dimensione, sempre. Ogni byte costa 4/3 di byte dopo la codifica. Una volta applicato gzip il sovraccarico apparente si riduce (perché Base64 è ripetitivo), ma i byte che il browser analizza sono comunque il 33% più grandi dell'originale.
2. L'immagine non può essere memorizzata nella cache separatamente. Un image.png esterno viene recuperato una volta e riutilizzato su ogni pagina che lo collega. Un'immagine Base64 vive dentro l'HTML o il CSS e viene riscaricata a ogni modifica di quel file.
3. Rallenta l'analisi di HTML e CSS. Lunghe stringhe incorporate dentro CSS che bloccano il rendering allontanano ulteriormente il percorso critico. Harry Roberts (CSS Wizardry) ha misurato un foglio di stile reale di un cliente a 925 KB con immagini Base64 contro 708 KB senza, e 232 KB compressi con gzip contro 68 KB. Rimuovere Base64 ha ridotto il CSS compresso con gzip del 70,68%.
4. Non può essere caricata in modo lazy. L'attributo loading="lazy" rinvia il recupero di un'immagine finché l'utente non scorre vicino ad essa. Le immagini Base64 sono già nel documento, non c'è nulla da rinviare.
5. HTTP/2 e HTTP/3 hanno già risolto il problema delle «troppe richieste». Il multiplexing permette a una singola connessione di consegnare centinaia di file in parallelo, quindi la giustificazione originale per l'incorporamento è in gran parte sparita.

Una regola pratica empirica da Google PageSpeed e dalla maggior parte degli autori di prestazioni: incorpora solo se l'immagine è sotto ~1-2 KB codificata, e solo se appare above the fold nel CSS critico. Qualsiasi cosa più grande quasi certamente rende meglio come file separato.

SVG: usa la codifica UTF-8, non Base64

L'SVG è già testo, quindi codificarlo come Base64 spreca ~33% di byte senza alcun beneficio. La forma più piccola è UTF-8 con codifica URL:

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

La maggior parte degli strumenti di build moderni (il postcss-inline-svg di PostCSS, lo svg-url-loader di Webpack) emette la forma con codifica URL per impostazione predefinita. Per l'SVG inline, preferisci quella forma a Base64 a meno che uno specifico consumatore non richieda ;base64.

Tipi MIME che questo strumento riconosce

Il prefisso del tipo di media del data URI è ciò che dice al consumatore come interpretare i byte. Il browser lo rileva dal file che selezioni:

Note su privacy e sicurezza

La maggior parte dei siti «da immagine a Base64» online carica il tuo file sul proprio server, lo codifica lì e restituisce il risultato. Ciò significa che screenshot di interfacce pre-rilascio, design coperti da NDA, foto di bambini, scansioni mediche o firme su contratti attraversano l'infrastruttura di terzi. Questo strumento codifica localmente, il FileReader del browser legge il file in memoria, il codificatore viene eseguito in JavaScript sul tuo dispositivo, e l'unica cosa che lascia la pagina è la stringa codificata quando la copi.

Due note sulla Content Security Policy che vale la pena conoscere se distribuisci immagini Base64 in produzione:

• Le immagini Base64 incorporate aggirano le regole img-src a meno che tu non le consenta esplicitamente. Una CSP rigorosa come img-src 'self' blocca gli URI data:. Per consentirli, scrivi img-src 'self' data:.
• Lo stesso vale per le immagini di sfondo incorporate nel CSS. Se una CSP sta bloccando i tuoi sfondi incorporati, controlla prima la direttiva img-src.

Errori comuni

1. Trattare Base64 come offuscamento. Non lo è. Chiunque può decodificarlo in due righe di qualsiasi linguaggio. Non mettere credenziali, chiavi API o dati sensibili dentro stringhe Base64 «per nasconderli».
2. Incorporare un'immagine hero da 200 KB. L'immagine diventa 266 KB codificata, resta bloccata dentro l'HTML, non può essere memorizzata nella cache separatamente, non può essere caricata in modo lazy, e il primo disegno della pagina è visibilmente più lento. Servila come un normale file.
3. Copiare il Base64 grezzo quando ti serviva il data URI. Una stringa Base64 nuda in un attributo <img src> viene resa come immagine non funzionante, ti serve il prefisso data:image/png;base64,. Usa il pulsante «Copy Data URI».
4. Codificare l'SVG in Base64. L'SVG è già testo. Codificalo invece con codifica URL e risparmia il 33% di sovraccarico.
5. Dimenticare la CSP. Un rigoroso img-src 'self' blocca i data URI. Aggiungi data: alla direttiva se distribuisci immagini Base64.
6. Provare a decodificare una stringa Base64 con un prefisso data: iniziale. La porzione data:image/...;base64, è metadato; rimuovila prima di passare la stringa a un decodificatore Base64.
7. Incollare immagini riservate in un codificatore lato server. Se l'URL dice «encode» ma la scheda di rete mostra un POST, la tua immagine ha appena lasciato la tua macchina.

Domande frequenti

Qual è la differenza tra «Base64» e «Data URI»?

Base64 è la codifica (una stringa come iVBORw0KGgo…. Un data URI è il contenitore che trasforma una stringa Base64 in qualcosa che può sostituire un URL di immagine) data:image/png;base64,iVBORw0KGgo…. Il contenitore dice al browser il tipo di media e la codifica così che sappia come interpretare i byte. I due pulsanti in questo strumento ti danno ciascuna forma separatamente.

Base64 è sicuro?

No, e non è a questo che serve. Base64 è codifica, non cifratura. La RFC 4648 §12 lo mette in modo diretto: «non fornisce alcuna riservatezza computazionale.» Chiunque può decodificare una stringa Base64 istantaneamente. Se hai bisogno di privacy, cifra prima i dati (con AES, ecc.) e poi codifica in Base64 il testo cifrato per il trasporto.

Quanto grande può essere l'immagine?

Non c'è alcun limite rigido imposto dallo strumento, dato che la codifica avviene nella memoria del tuo browser. Il tetto pratico è quanto il tuo dispositivo può contenere, tipicamente decine di MB vanno bene sui laptop moderni. Il vincolo più grande è il supporto dei consumatori: molti client di posta, browser e API hanno i propri limiti di dimensione dei data URI, e incorporare qualsiasi cosa oltre pochi KB raramente ha senso per le prestazioni.

Perché la mia stringa Base64 è il 33% più grande del file?

Perché ogni carattere Base64 porta 6 bit, mentre ogni byte di input porta 8 bit. La più piccola unità che Base64 può rappresentare senza resto è 3 byte (24 bit = quattro caratteri da 6 bit), quindi il rapporto di output è esattamente 4/3 ≈ 1,33. Non c'è alcuna variante di Base64 che eviti questo, è matematicamente radicato nella codifica.

L'immagine codificata funzionerà nelle e-mail HTML?

Per lo più, ma non sempre. Apple Mail, il Gmail moderno e la maggior parte dei client webmail rendono le immagini data: in modo pulito. Microsoft Outlook desktop ha storicamente avuto un supporto incoerente, alcune versioni rendono i data URI bene, altre li rimuovono del tutto. Fai delle prove nella tua lista di client di destinazione prima di affidarti a immagini Base64 nelle e-mail transazionali. Per un'ampia compatibilità, gli URL di immagini ospitate restano la scommessa più sicura.

Dovrei usare invece base64url (con - e _)?

Solo se stai mettendo i dati codificati in un URL o nome di file dove + e / avrebbero altrimenti bisogno della codifica percentuale. Per gli attributi HTML <img src> e i valori CSS background-image, l'alfabeto standard funziona. La RFC 4648 §5 definisce la variante sicura per URL esplicitamente per quei casi di URL/nome di file, e avverte che «non dovrebbe essere indicata solo come 'base64'» per evitare confusione con l'alfabeto standard.

Strumenti correlati