Base64 Encoder e Decoder Online

Base64 fu sviluppato negli anni '90 per risolvere un problema critico: trasmettere dati binari (immagini, file, eseguibili) attraverso sistemi progettati solo per testo ASCII a 7 bit, come le email SMTP tradizionali.

Il predecessore era UUENCODE (Unix-to-Unix Encoding), introdotto nel 1980, ma usava caratteri meno affidabili e aveva problemi di compatibilità cross-platform. Base64 è diventato standard con il MIME (Multipurpose Internet Mail Extensions) nel 1996 (RFC 2045) per allegati email.

Lo standard attuale è definito nella RFC 4648 (2006), che specifica 3 varianti: Base64 standard, Base64 URL-safe (usato in JWT e OAuth), e Base32 (alfabeto più ridotto per sistemi case-insensitive).

Uso Moderno: Oggi Base64 è onnipresente nello sviluppo web. I JSON Web Tokens (JWT) usano Base64 URL-safe per codificare header e payload. Le API RESTful trasmettono file binari in JSON usando Base64. I browser supportano nativamente btoa() (encode) e atob() (decode).

Data URI in HTML/CSS: includere immagini piccole (icone, loghi) direttamente nel codice, senza una richiesta HTTP separata:

<img src="data:image/png;base64,iVBORw0KG..." />

Allegati Email (MIME): Quando mandi email con attachment, il client codifica PDF, immagini, ZIP in Base64 per compatibilità con server email che gestiscono solo testo ASCII a 7 bit.

JWT e Autenticazione API: I token JWT (JSON Web Tokens) sono 3 stringhe Base64 separate da punti: header.payload.signature. Esempio: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Dati binari dentro JSON/XML: JSON non supporta dati binari nativamente. Per inviare un file via API JSON, devi codificarlo in Base64. Attenzione però a un equivoco comune: non tutti i database memorizzano i binari in Base64. MongoDB conserva i dati binari in modo nativo nel tipo BinData del formato BSON, non come stringa Base64 (la rappresentazione Base64 compare solo quando il documento viene serializzato in JSON, ad esempio in mongoexport). Il localStorage del browser, invece, memorizza sempre stringhe UTF-16: è lo sviluppatore che, se deve salvarvi dati binari, sceglie di codificarli prima in Base64.

Font e asset inline: i font web (@font-face) e il CSS possono includere file WOFF/TTF codificati in Base64 per ridurre il numero di richieste HTTP in applicazioni dove la performance è critica.

Esempio: Codificare "Man"

1. Converti in ASCII:
   M = 77, a = 97, n = 110
2. Binario a 8 bit:
   01001101 01100001 01101110 (24 bit totali)
3. Raggruppa in 6 bit:
   010011 | 010110 | 000101 | 101110
4. Converti in decimale:
   19, 22, 5, 46
5. Mappa su caratteri Base64:
   Alfabeto: A-Z (0-25), a-z (26-51), 0-9 (52-61), + (62), / (63)
   19=T, 22=W, 5=F, 46=u → Risultato: TWFu

Padding con =: Se i byte input non sono multipli di 3, si aggiunge padding. "Ma" (2 byte) → TWE=, "M" (1 byte) → TQ==. Ogni = rappresenta 6 bit mancanti.

Overhead del 33%: Base64 aumenta sempre la dimensione del 33% perché trasforma 3 byte (24 bit) in 4 caratteri (4×6=24 bit, ma ogni carattere occupa 8 bit). Quindi 3 byte → 4 byte. Un file da 1MB diventa 1.33MB codificato.

Errore #1: Base64 NON è crittografia
Base64 è una codifica, non una cifratura. Chiunque può decodificarla in un istante con atob() o con questo strumento. Non usarla per "nascondere" password o dati sensibili: per quello servono AES, RSA o funzioni di hash (SHA-256, bcrypt).

Errore #2: Variante Standard vs URL-safe
Base64 standard usa + e /, ma questi caratteri hanno significato speciale negli URL. La variante URL-safe sostituisce: + → -, / → _, e omette padding =. JWT usa sempre URL-safe.

Errore #3: a capo nelle stringhe codificate
Alcuni encoder (es. OpenSSL, client email) inseriscono un a capo ogni 64 o 76 caratteri per leggibilità, come previsto da MIME (RFC 2045). Da specifica, l'algoritmo forgiving-base64 decode alla base di atob() rimuove da solo tutti gli spazi bianchi (inclusi gli a capo) prima di decodificare, quindi nei browser conformi questi non causano errori. Il problema si presenta invece con altre librerie più rigide: in quei casi pulisci l'input con .replace(/\s/g, "") prima di decodificare.

Errore #4: padding mancante o caratteri illegali
Contrariamente a quanto si legge spesso, atob() tollera l'assenza dei caratteri di padding = finali: l'algoritmo li tratta come opzionali. Lancia però un InvalidCharacterError in due casi precisi: se, rimossi spazi e padding, la lunghezza diviso 4 dà resto 1 (sequenza impossibile), oppure se l'input contiene caratteri fuori dall'alfabeto Base64 standard. Nota: atob() decodifica solo Base64 standard, non la variante URL-safe (con - e _), che va prima riconvertita.

Un JWT (JSON Web Token) è formato da tre parti separate da un punto: header.payload.signature. Header e payload sono semplicemente JSON codificati in Base64URL (la variante URL-safe), quindi sono leggibili da chiunque. La firma, invece, NON è cifrata né decodificabile in testo: serve solo a verificare l'integrità tramite una chiave segreta. Decodifichiamo solo l'header.

1. Header Base64URL di partenza:
   eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
2. Decodifica i caratteri in byte usando l'alfabeto Base64: i primi 4 caratteri eyJh diventano i byte 123, 34, 97, cioè i caratteri ASCII {"a.
3. Continua fino alla fine e i byte ricostruiti formano il testo:
   {"alg":"HS256","typ":"JWT"}

L'header dichiara dunque che il token è firmato con l'algoritmo HS256 (HMAC-SHA256). Puoi verificarlo tu stesso: la stringa SGVsbG8= decodifica esattamente in Hello (i byte 72, 101, 108, 108, 111).

Importante: poter leggere header e payload NON significa poter falsificare il token. Senza la chiave segreta la firma non è ricalcolabile, quindi non inserire mai dati riservati (password, dati personali) nel payload di un JWT.