Base64 è uno di quei formati che ogni sviluppatore ha usato ma pochi riescono a spiegare senza esitare. Sembra caratteri casuali. Rende i dati più grandi. Eppure è la spina dorsale degli allegati email, dei payload JWT, delle immagini inline in CSS e di dozzine di altri protocolli che devono spostare dati binari su canali di solo testo.
La versione breve: Base64 codifica dati binari arbitrari come caratteri ASCII stampabili. La versione lunga coinvolge un alfabeto di 64 caratteri, regole di riempimento e alcune varianti che ingannano le persone in produzione.
Perché esiste Base64
Molti sistemi sono stati progettati per trasportare solo testo — email (SMTP), URL, XML, JSON. Se vuoi inviare un file binario attraverso una di queste pipeline, hai bisogno di un modo per rappresentare i byte come caratteri. Base64 risolve questo mappando ogni 3 byte di input in 4 caratteri di output, usando solo caratteri sicuri praticamente in ogni protocollo di testo.
Il compromesso: Base64 aumenta la dimensione dei dati di circa il 33%. Un’immagine da 1KB diventa circa 1,3KB di testo. Per la maggior parte dei casi d’uso va bene. Per sistemi ad alto throughput conta, e vedrai alternative come Base85 o protocolli binari raw.
I 64 caratteri
L’alfabeto è:
A-Z (26 caratteri)
a-z (26 caratteri)
0-9 (10 caratteri)
+ / (2 caratteri)Sono 64 caratteri in totale, da cui il nome. Il carattere = viene usato per il riempimento quando la lunghezza dell’input non è un multiplo di 3 byte.
Ogni carattere nell’alfabeto è ASCII stampabile, il che significa che l’output di Base64 può passare attraverso le email, apparire in stringhe JSON, trovarsi all’interno di attributi HTML e sopravvivere a sistemi che potrebbero danneggiare i dati binari raw.
Come funziona la codifica
Prendi tre byte di input. Ogni byte ha 8 bit, quindi hai 24 bit in totale. Base64 divide questi 24 bit in quattro gruppi da 6 bit. Ogni gruppo da 6 bit viene mappato a un carattere nell’alfabeto:
000000→A000001→B- …
111111→z
È tutto. La codifica è una semplice trasformazione a livello di bit senza chiave, sale o segreto. Chiunque può decodificare Base64 invertendo la tabella di lookup.
Riempimento
Se la lunghezza dell’input non è un multiplo di 3, il riempimento colma la lacuna:
- 1 byte rimasto → 2 caratteri Base64 +
== - 2 byte rimasti → 3 caratteri Base64 +
= - 0 byte rimasti → nessun riempimento
I caratteri di riempimento non trasportano dati. Esistono per rendere la lunghezza dell’output sempre un multiplo di 4, che molti parser si aspettano.
Varianti
Non tutto il Base64 è identico:
- Base64 standard (
A-Za-z+/=) — il predefinito, usato nelle email MIME e nella maggior parte dei protocolli. - Base64 sicuro per URL (
A-Za-z-_) — sostituisce+con-e/con_, rimuove il riempimento. Usato nei JWT, nei parametri URL e nei nomi file. - Base64 senza riempimento — alcuni sistemi omettono i caratteri
=. L’output è più corto ma alcuni parser falliscono.
Quando stai facendo debug di un JWT o data URI e la decodifica fallisce, la prima cosa da controllare è se il codificatore ha usato Base64 sicuro per URL o Base64 standard. Un - nel mezzo di quello che ti aspettavi fosse una stringa Base64 standard è l’indizio.
Dove gli sviluppatori incontrano davvero Base64
Allegati email. MIME (RFC 2045) usa Base64 per codificare gli allegati binari. Se hai mai visto un file .eml con lunghe stringhe di caratteri casuali, è contenuto codificato in Base64.
Payload JWT. Le tre parti di un JWT (header, payload, firma) sono ciascuna codificate in Base64 sicuro per URL. Quando decodifichi un JWT, stai invertendo la codifica Base64url su ogni segmento.
Data URI. data:image/png;base64,iVBOR... ti permette di incorporare un’immagine direttamente in HTML o CSS. I byte dell’immagine sono codificati in Base64 affinché possano apparire in un attributo di testo.
API. Alcune API accettano o restituiscono dati binari codificati in Base64 (upload di file, elaborazione immagini, firme crittografiche). È meno comune ora che la maggior parte delle API supporta dati multipart, ma appare ancora.
Embedding. I modelli di machine learning a volte memorizzano gli embedding come stringhe Base64 in JSON. Non è ideale per le prestazioni, ma è comodo per il trasporto.
Quando NON usare Base64
Non usarlo per la crittografia. Base64 è una codifica, non crittografia. Chiunque può decodificarla. Se stai mettendo dati sensibili in Base64, stai solo oscurandoli, non proteggendoli.
Non usarlo per la compressione. Base64 rende i dati più grandi, non più piccoli. Se stai codificando in Base64 dati già compressi (come un file .gz), stai aggiungendo overhead senza vantaggi.
Non usarlo in percorsi critici per le prestazioni. La codifica/decodifica aggiunge tempo CPU e aumenta la dimensione del payload. Per API interne ad alta frequenza, usa protocolli binari (protobuf, msgpack) invece.
Non dimenticare la variante. Se stai generando Base64 per un URL o JWT, usa Base64 sicuro per URL. Se stai generando per email o trasporto generale, usa Base64 standard. Mescolarli causa corruzione silenziosa dei dati.
Riferimento rapido | Scenario | Variante | Riempimento | |–––––|–––––|–––––| | JWT | Sicuro per URL | No | | Email / MIME | Standard | Sì | | Data URI | Standard | Opzionale | | Parametro URL | Sicuro per URL | No | | Trasporto generale | Standard | Sì |
Prova
Se hai una stringa Base64 da decodificare o dati binari da codificare, usa uno strumento basato su browser affinché la conversione avvenga localmente — i tuoi dati non vengono inviati a un server per qualcosa di così semplice.