Base64 trasforma byte qualsiasi in una stringa di 64 caratteri sicuri, così che dati mai pensati per essere testo possano attraversare canali che accettano solo testo. È nato per gli allegati email negli anni Novanta ed è ancora ovunque: data URI, JWT, header di autenticazione HTTP Basic, payload JSON che trasportano blob binari.
Cosa fa davvero la codifica
L'encoder legge l'input tre byte alla volta. Tre byte sono 24 bit, che vengono ritagliati in quattro gruppi da sei bit. Sei bit contengono 64 valori, e ognuno di quei valori corrisponde a un carattere dell'alfabeto A–Z, a–z, 0–9, più "+" e "/". Il trucco è tutto qui.
Quando la lunghezza dell'input non è multipla di tre, l'ultimo gruppo resta corto e l'encoder riempie l'output con uno o due caratteri "=", così il risultato è sempre divisibile per quattro. Ecco perché alcune stringhe finiscono con l'uguale e altre no: ti dice la lunghezza originale modulo 3, niente di più.
Il 33% che paghi
Quattro caratteri in uscita ogni tre byte in ingresso significa che l'output Base64 pesa circa il 33% in più dell'input. Un'immagine da 900 KB diventa circa 1,2 MB di testo. Il punto pesa soprattutto dove le persone ricorrono a Base64 più volentieri: incorporare immagini come data URI dentro CSS o HTML.
Incorporare risparmia una richiesta HTTP, cosa che valeva molto con HTTP/1.1 e vale molto meno con HTTP/2 e HTTP/3, dove le richieste sono multiplexate. Il costo invece è reale: un'immagine incorporata non può essere messa in cache separatamente dal documento, quindi ogni modifica alla pagina la riscarica, e ogni visita la riscarica insieme all'HTML. Come regola pratica: incorporare ha senso per risorse minuscole — un'icona di poche centinaia di byte — ed è un errore per le fotografie.
Base64 non è cifratura
È il malinteso più diffuso in assoluto, e provoca incidenti veri. Base64 non ha una chiave. Chiunque abbia la stringa la decodifica in un passaggio, incluso il browser da cui stai leggendo. Codificare una password, un token API o l'anagrafica di un cliente in Base64 non protegge nulla: rende solo il valore illeggibile a un umano che scorre un file di log, che non è una proprietà di sicurezza.
Un JWT lo rende concreto. Header e payload sono Base64url, non cifrati: incollane uno in un decoder e leggerai ogni claim che contiene. La firma impedisce di *modificare* il token, non di *leggerlo*. Non mettere mai nel payload di un JWT qualcosa che chi possiede il token non dovrebbe vedere.
La variante URL-safe
Il Base64 standard usa "+" e "/", e in un URL entrambi significano altro: "+" può essere letto come spazio in una query string, e "/" è un separatore di percorso. La variante base64url definita nella RFC 4648 §5 li sostituisce con "-" e "_", e di solito elimina il padding. Se un token che stai decodificando contiene "-" o "_" e nessun "=", quasi certamente stai guardando base64url — che è quello che usano i JWT.
Domande frequenti
I miei dati vengono inviati a un server?
No. Questo strumento è marcato "client": la codifica gira nella scheda del tuo browser col suo motore JavaScript, e quello che scrivi non lascia mai la macchina. Chiudi la scheda e non resta niente. Detto questo, se i dati sono davvero sensibili usa uno strumento controllato dalla tua organizzazione invece di una qualsiasi pagina web gratuita — questa inclusa.
Perché il testo decodificato mostra caratteri strani?
Quasi sempre è un disallineamento di codifica caratteri. Base64 codifica byte, non caratteri, quindi non può sapere se quei byte dovevano essere UTF-8, Latin-1 o altro. Se il testo originale era UTF-8 e viene interpretato come Latin-1, le lettere accentate diventano coppie tipo "Ã ". Il passaggio Base64 è corretto; è l'interpretazione successiva a non esserlo.
Perché btoa() e atob() di JavaScript si rompono sulle lettere accentate?
Perché precedono il supporto Unicode e gestiscono solo caratteri nell'intervallo 0–255. Passare "è" a btoa() lancia un InvalidCharacterError. La soluzione moderna è convertire prima in byte con TextEncoder e poi codificare quei byte — che è esattamente ciò che questo strumento fa per te.
C'è un limite di dimensione?
Nessuno imposto dallo strumento, ma uno pratico imposto dal tuo dispositivo. Tutto avviene in memoria, e la copia codificata è un terzo più grande dell'input, quindi file molto grandi rallenteranno la scheda prima che qualcosa fallisca davvero. Per binari da diversi megabyte, uno strumento da riga di comando è più adatto.