Cosa è la Codifica Base64? Guida con Esempi Reali
Base64 è un modo per rappresentare dati binari o testo usando solo 64 caratteri ASCII stampabili (lettere maiuscole, minuscole, cifre, più il simbolo + e /), così quei dati possono attraversare sistemi che gestiscono in modo sicuro solo testo puro. Non è crittografia: è solo un cambio di formato, completamente reversibile da chiunque.
Cosa fa davvero la codifica Base64
L’alfabeto Base64 ha 64 simboli: A-Z, a-z, 0-9, più + e /, con = riservato come carattere di riempimento (padding). Ogni gruppo di 3 byte in ingresso diventa esattamente 4 caratteri Base64 in uscita, quindi il risultato finale è circa il 33% più grande dell’originale.
Vale la pena chiarirlo subito, perché è l’equivoco più comune: Base64 non è crittografia e non è compressione. Non esiste una chiave segreta, chiunque può decodificare una stringa Base64 in una frazione di secondo, e l’output è sempre più grande, mai più piccolo, dell’input. Se codifichi una password in Base64 e la memorizzi così pensando di averla “protetta”, non hai protetto nulla: hai solo reso la password leggermente meno leggibile a occhio nudo. Per proteggere dati serve cifratura vera, con una chiave; Base64 serve solo a far viaggiare dati binari dentro canali pensati per il testo.
Come funziona: codificare “Man” bit per bit
Non è magia, è conversione tra basi numeriche: da byte a 8 bit a blocchi da 6 bit. Prendiamo la parola inglese “Man” come esempio classico, perché mostra bene la meccanica.
Ogni carattere ha un valore ASCII: M=77, a=97, n=110. In binario:
| Carattere | Valore ASCII | Binario (8 bit) |
|---|---|---|
| M | 77 | 01001101 |
| a | 97 | 01100001 |
| n | 110 | 01101110 |
Concatenando i tre byte si ottengono 24 bit di fila: 010011010110000101101110. Base64 non legge questi bit a gruppi di 8 (byte), ma a gruppi di 6, perché 2^6 = 64, esattamente il numero di simboli nell’alfabeto. Dividendo i 24 bit in quattro blocchi da 6 bit si ottiene:
| Blocco a 6 bit | Valore decimale | Carattere Base64 |
|---|---|---|
| 010011 | 19 | T |
| 010110 | 22 | W |
| 000101 | 5 | F |
| 101110 | 46 | u |
Il risultato è “TWFu”. Ogni blocco da 6 bit viene tradotto in decimale (19, 22, 5, 46) e quel numero indica la posizione del carattere corrispondente nell’alfabeto Base64. Nessun segreto: è aritmetica pura, la stessa che il tuo browser esegue istantaneamente quando incolli del testo nell’encoder qui sotto.
Padding: perché alcune stringhe Base64 finiscono con =
Il sistema a blocchi da 3 byte funziona benissimo quando l’input è un multiplo esatto di 3. Ma cosa succede quando non lo è? Qui entra in gioco il padding, il carattere =.
| Input | Byte | Output Base64 | Perché |
|---|---|---|---|
| ”M” | 1 byte | TQ== | 1 byte non riempie un gruppo da 3; risultano 2 caratteri di dati reali più 2 di padding |
| ”Ma” | 2 byte | TWE= | 2 byte producono 3 caratteri di dati reali più 1 di padding |
| ”Man” | 3 byte | TWFu | 3 byte riempiono il gruppo esattamente, 4 caratteri, nessun padding |
Il segno = non codifica nulla: è solo un segnaposto che dice “qui il gruppo di byte originale era incompleto”. Un decoder rigoroso lo controlla per capire dove finiscono i dati reali. È per questo che alcune stringhe Base64 finiscono con uno o due segni di uguale e altre no.
Dove incontri Base64 nella vita reale
Base64 è ovunque nei sistemi che devono spedire dati binari o strutturati attraverso canali pensati per il testo. Alcuni esempi concreti, con i risultati reali che ottieni codificando ciascuna stringa:
Autenticazione HTTP Basic. Quando un’API richiede Authorization: Basic <credenziali>, il browser prende utente:password, lo codifica in Base64 e lo manda nell’header. Per esempio user:pass1234 diventa dXNlcjpwYXNzMTIzNA==. Attenzione: questo non protegge la password in transito, la rende solo trasportabile come testo. La protezione reale arriva da HTTPS, non da Base64.
Payload JSON dentro URL o parametri. Un piccolo blocco JSON come {"id":42,"active":true} diventa eyJpZCI6NDIsImFjdGl2ZSI6dHJ1ZX0=. Utile quando serve incorporare dati strutturati in un posto che si aspetta solo testo semplice, come un parametro di query.
Data URL in CSS e HTML. Un’immagine piccola può essere incorporata direttamente nel markup con data:image/png;base64,... invece di un link a un file esterno, evitando una richiesta HTTP separata.
Allegati email (MIME). I protocolli email storicamente gestiscono solo testo ASCII, quindi allegati binari come PDF o immagini vengono codificati in Base64 prima dell’invio e decodificati dal client di posta in arrivo.
Token JWT. Un JSON Web Token è composto da tre segmenti separati da punti: header.payload.signature. Header e payload sono codificati in Base64URL (una variante, vedi sotto), non cifrati: il segmento payload si può decodificare con un normale decoder Base64/Base64URL, esattamente quello che trovi qui sotto, per leggere i claim contenuti (ID utente, ruoli, scadenza). La firma invece garantisce l’integrità, non la segretezza del contenuto.
Un paio di esempi con il testo comune “Hello, World!” mostra la stessa meccanica: la stringa diventa SGVsbG8sIFdvcmxkIQ==, sempre seguendo le stesse regole di blocchi da 3 byte e padding.
Codifica o decodifica il tuo testo
Prova tu stesso: scrivi del testo nell’encoder qui sotto e osserva l’output cambiare in tempo reale, oppure incolla una stringa Base64 nel decoder per vedere cosa contiene davvero.
Errori comuni e casi limite
Trattare Base64 come sicurezza. Vale la pena ripeterlo in modo esplicito: usare Base64 al posto della cifratura è un antipattern di sicurezza, non un dettaglio tecnico trascurabile. Se un dato è sensibile, cifralo con un algoritmo vero prima di trasmetterlo o salvarlo. Base64 non nasconde nulla a chi sa cosa sta guardando.
Confondere Base64 standard con Base64URL. L’alfabeto standard usa + e / come parte dei suoi 64 simboli, ma questi due caratteri hanno un significato speciale dentro un URL o una query string, dove possono essere alterati o creare ambiguità. Per questo esiste una variante, Base64URL, che sostituisce + con - e / con _, spesso omettendo anche il padding. È il motivo per cui alcune stringhe Base64 che vedi in un URL o in un JWT non hanno + né / né =: sono nella variante URL-safe, non in quella classica.
Spazi bianchi o padding mancante che rompono la decodifica. Un decoder rigoroso può rifiutare una stringa se contiene interruzioni di riga, spazi accidentali o se il padding finale è stato tagliato via da qualche sistema intermedio. Se una decodifica fallisce inaspettatamente, controlla prima questi dettagli.
Testo UTF-8 multi-byte che codifica più byte di quanti caratteri sembri contenere. La parola “café” ha 4 caratteri visibili, ma la é occupa 2 byte in UTF-8, quindi la codifica è a livello di byte, non di carattere: il risultato è Y2Fmw6k=, 8 caratteri Base64, non i 6 che ti aspetteresti contando solo le lettere. Lo stesso vale per un’emoji come 🚀, che occupa 4 byte UTF-8 e diventa 8J+agA==: un singolo carattere “grande” viene comunque trattato byte per byte, senza trattamento speciale.
Doppia codifica per errore. Se codifichi in Base64 una stringa che è già Base64, il risultato è una nuova stringa valida ma inutile: decodificandola una sola volta ottieni ancora testo Base64 illeggibile, non il dato originale. Serve decodificare due volte per tornare all’origine. È un errore facile quando uno script o una libreria codifica automaticamente input che era già stato codificato a monte.
Domande frequenti
Base64 è sicuro da usare per password o dati sensibili? No. Base64 è completamente reversibile e non richiede alcuna chiave: chiunque intercetti la stringa può decodificarla all’istante. Per proteggere dati sensibili serve cifratura vera con una chiave segreta, oppure, nel caso di password, un hashing dedicato come bcrypt o Argon2.
Perché l’output Base64 è sempre più lungo del testo originale? Perché ogni gruppo di 3 byte (24 bit) viene ridistribuito in 4 caratteri da 6 bit ciascuno. Questo rapporto 3:4 fa crescere l’output di circa il 33% rispetto ai byte originali, indipendentemente dal contenuto.
Qual è la differenza tra Base64 e Base64URL? L’alfabeto è quasi identico, ma Base64URL sostituisce i due caratteri problematici per gli URL, + e /, rispettivamente con - e _, e spesso omette il padding finale. Si usa in contesti come URL, nomi di file e i segmenti di un token JWT, dove un + o uno / originali potrebbero essere interpretati male dal sistema che legge la stringa.
Posso decodificare direttamente un token JWT con questo strumento? Il decoder qui sopra decodifica correttamente il testo Base64/Base64URL che gli incolli, quindi puoi prendere il segmento payload di un JWT (la parte centrale tra i due punti) e incollarlo per leggere i claim in chiaro. Non è uno strumento specializzato per JWT con parsing automatico dei tre segmenti, ma il meccanismo di decodifica sottostante è esattamente lo stesso.
Perché un file codificato in Base64 pesa di più del file originale? Per lo stesso motivo per cui il testo si allunga: ogni 3 byte binari diventano 4 caratteri di testo. Un’immagine da 300 KB incorporata come data URL Base64 occupa circa 400 KB nel markup che la contiene, un costo che vale la pena considerare prima di scegliere questo approccio per file grandi.