Codificatore e decodificatore Base64 gratuito online

Cos'è Base64?

Base64 è uno schema di codifica binario-a-testo, un modo di rappresentare qualsiasi sequenza di byte (dati binari) come una sequenza di caratteri ASCII semplici che possono viaggiare attraverso canali solo-testo senza corruzione. Il nome riflette la dimensione dell'alfabeto: 64 caratteri scelti specificamente perché sopravvivono inalterati alla trasmissione 7-bit-clean. L'alfabeto standard è A-Z (posizioni 0-25), a-z (26-51), 0-9 (52-61), poi + (62) e / (63). Il carattere = è riservato come padding quando la lunghezza dell'input non è un multiplo esatto di tre. Ogni tre byte di input (24 bit) diventano quattro caratteri di output (ciascuno che trasporta 6 bit), motivo per cui i dati codificati in Base64 sono circa il 33% più grandi dell'originale.

Il meccanismo: prendi tre byte (24 bit), ri-raggruppali come quattro chunk da 6 bit, cerca ogni chunk nell'alfabeto di 64 caratteri. L'esempio classico elaborato: i tre byte ASCII M a n (0x4D 0x61 0x6E) formano il pattern a 24 bit 01001101 01100001 01101110; ri-raggruppato in chunk da 6 bit: 010011 010110 000101 101110 = decimale 19, 22, 5, 46 = caratteri T W F u. Quindi "Man" codifica in Base64 a "TWFu". Se la lunghezza dell'input non è divisibile per tre, l'encoder fa padding con uno o due caratteri =: 1 byte di input produce 2 caratteri + ==, 2 byte di input producono 3 caratteri + =.

Una breve storia di Base64

Base64 è nato nello sforzo di Privacy Enhanced Mail (PEM) dell'IETF. RFC 989 nel febbraio 1987 è stata la prima definizione formale; RFC 1113 nell'agosto 1989 l'ha rivista; RFC 1421 nel febbraio 1993 ha finalizzato la specifica PEM con la codifica Base64 inclusa. Base64 è entrata nel mainstream email quando la specifica MIME (Multipurpose Internet Mail Extensions) l'ha adottata: RFC 2045 nel novembre 1996 ha definito Base64 come la codifica standard per allegati email binari, motivo per cui ogni PDF o immagine che hai mai allegato a un'email ha viaggiato attraverso il filo come Base64. La specifica canonica attuale è RFC 4648 ("The Base16, Base32, and Base64 Data Encodings"), pubblicata nell'ottobre 2006 da Simon Josefsson, che ha sostituito RFC 3548 (luglio 2003) e ha unificato le varie codifiche della famiglia Base16 / Base32 / Base64 in un singolo documento. RFC 4648 è la spec che ogni implementazione Base64 moderna mira.

Base64 URL-safe, perché due caratteri vengono scambiati

L'alfabeto Base64 standard usa + e /, entrambi caratteri riservati negli URL. + in una query string URL tipicamente significa "spazio" (convenzione form-encoded); / è il separatore di percorso. Mettere Base64 standard in un URL significa percent-encoding di entrambi, il che gonfia ulteriormente la stringa e la rende brutta. RFC 4648 §5 definisce una variante URL-safe: sostituisci + con - (trattino-meno) e / con _ (underscore). A volte chiamato Base64URL o base64url. Il risultato è una stringa che si inserisce direttamente negli URL senza ulteriore escape, esattamente quello che usano JWT (JSON Web Tokens), parametri di stato OAuth, ID di credenziali WebAuthn e la maggior parte delle API web moderne. Alcune implementazioni eliminano anche il padding finale = perché la lunghezza è implicita dal campo successivo. La struttura a tre parti separata da punti del JWT (header.payload.signature) sono tre segmenti codificati Base64URL; se hai mai decodificato un JWT manualmente, hai visto i caratteri - e _ che lo segnano come Base64URL piuttosto che Base64 standard.

La famiglia Base-N, Base16, Base32, Base58, Base85

Base64 non è l'unica codifica binario-a-testo. Base16 (hex) usa 16 caratteri (0-9 e A-F), 100% di espansione di dimensione (ogni byte diventa 2 caratteri hex), ma banalmente leggibile e il default universale per output hash, checksum di file e identificatori macchina. Base32 (RFC 4648, anche la variante di Crockford) usa 32 caratteri con cura nell'escludere coppie visivamente ambigue come 0/O e 1/I/L; 60% di espansione di dimensione; usato in chiavi segrete TOTP, ULID e indirizzi Tor onion. Base58 è canonico di Bitcoin: 58 caratteri escludendo i facilmente confusi 0/O/I/l, più i caratteri speciali Base64 standard +/=. Indirizzi Bitcoin, indirizzi Solana, e molti identificatori di wallet crypto usano Base58Check (Base58 più un checksum di 4 byte). Base85 / Ascii85 impacchetta più densità (codificando 4 byte come 5 caratteri, solo 25% di espansione) ma usa un alfabeto che include punteggiatura URL-unsafe; i formati PostScript e PDF di Adobe usano Base85 internamente per dati binari incorporati. Il compromesso generale: più caratteri nell'alfabeto significano meno espansione ma un set di caratteri più vincolato; meno caratteri significano trasporto più sicuro al costo di un output più grande.

Usi comuni di Base64

• Allegati email (MIME). RFC 2045 dal 1996. Ogni PDF, immagine o documento che hai mai allegato a un'email ha viaggiato la rete come Base64 perché SMTP era originariamente un protocollo di testo 7-bit-clean che non poteva gestire binario grezzo.
• URI data: in HTML/CSS. data:image/png;base64,iVBORw0KGgo... incorpora una piccola immagine direttamente in HTML o in un foglio di stile CSS, eliminando una richiesta HTTP. Utile per icone sotto i ~10 KB; controproducente per immagini più grandi perché l'espansione del 33% di Base64 supera l'overhead di richiesta HTTP risparmiato.
• Binario in payload JSON. JSON è solo-testo per specifica, non c'è modo di mettere byte grezzi in un valore JSON. Le API che devono trasmettere immagini, PDF o altri binari li incorporano come stringhe Base64 in un campo JSON. I payload webhook di Stripe, le API MMS di Twilio e molti endpoint di vision AI usano questo pattern.
• JWT (JSON Web Tokens). Le tre parti separate da punti di un JWT (header.payload.signature) sono tutte codificate in Base64URL. La specifica JWT (RFC 7519, maggio 2015) si basa su JOSE (RFC 7515-7518, anche maggio 2015), tutti i quali mandano Base64URL ovunque.
• OAuth e OpenID Connect. Il parametro state, i code verifier PKCE, gli ID token e gli access token in molte implementazioni usano Base64URL.
• HTTP Basic Authentication. L'header Authorization: Basic dXNlcjpwYXNz trasporta Base64(username:password). Nota: questa è codifica per trasporto, NON crittografia, Basic Auth su HTTP semplice espone le credenziali in chiaro a chiunque guardi la rete. Accoppia sempre con HTTPS.
• Subresource Integrity (SRI). L'attributo integrity="sha384-..." sui tag <script> e <link> trasporta un hash codificato Base64 dei contenuti del file attesi; i browser verificano che il file scaricato corrisponda prima dell'esecuzione.
• Sfondi SVG-in-CSS. background-image: url("data:image/svg+xml;base64,...") incorpora un SVG direttamente in un foglio di stile. La forma Base64 è talvolta preferita alla forma URL-encoded (che mantiene l'SVG leggibile ma usa regole di escape diverse).

Codifica non è crittografia, un errore di sicurezza comune

Base64 offre zero sicurezza. La codifica è completamente reversibile da chiunque in millisecondi, l'alfabeto è pubblico, l'algoritmo è banale, e qualsiasi browser o comando CLI di una riga può decodificarlo. Nonostante questo, "dati sensibili codificati in Base64" è uno degli esempi più citati in CWE-261 di MITRE (Weak Encoding for Password) e appare costantemente negli audit di sicurezza: chiavi API "offuscate" con Base64 nel codice client; password "codificate" con Base64 in file di backup di database; segreti "crittografati" con Base64 prima di essere committati a un repository Git pubblico. Nessuno di questi è protetto. Se hai bisogno di confidenzialità effettiva, usa crittografia reale: AES-256-GCM per simmetrico, RSA-OAEP o ECDH+ChaCha20-Poly1305 per asimmetrico. Base64 è appropriato per il trasporto (trasformare binario in una forma adatta al testo) ma mai per la protezione.

Implementazione del browser: btoa / atob e la trappola Unicode

JavaScript espone due funzioni globali integrate per Base64: btoa() (binary-to-ASCII, codifica) e atob() (ASCII-to-binary, decodifica). Entrambe sono API legacy dall'era di Netscape antica e hanno una limitazione famosa: funzionano solo su stringhe di byte Latin-1. Chiamare btoa('é') lancia InvalidCharacterError perché la stringa JavaScript 'é' contiene un code point sopra U+00FF che non si adatta a un singolo byte. La correzione moderna è codificare in byte UTF-8 prima tramite TextEncoder, poi convertire il risultante Uint8Array in una stringa Latin-1 per il consumo di btoa(). Il pattern: btoa(String.fromCharCode(...new TextEncoder().encode(str))). La decodifica inversa: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). I browser più recenti espongono Uint8Array.toBase64() e Uint8Array.fromBase64() come metodi integrati, ma l'adozione si sta ancora diffondendo al 2026, il polyfill tramite btoa/atob rimane il default cross-browser. Per i file specificamente, FileReader.readAsDataURL() è il percorso più semplice: rilascia un file in un input, il reader restituisce una stringa data:mime/type;base64,... con tutto codificato correttamente; rimuovi il prefisso data: per ottenere solo la porzione Base64.

Ambito onesto: cosa fa e cosa non fa questo strumento

Questo strumento codifica testo o file (fino a 5 MB) in Base64 e decodifica stringhe Base64 di nuovo in testo o file scaricabili. Usa l'alfabeto standard RFC 4648 (con + e /) di default; Base64URL URL-safe (con - e _) è un toggle di feature futura. Il testo UTF-8 è gestito correttamente tramite TextEncoder, la trappola btoa-Latin-1 è risolta. Il limite di dimensione di 5 MB esiste perché Base64 espande i dati del 33% e la stringa codificata vive interamente nella memoria del browser; un file binario di 5 MB produce ~6,7 MB di testo Base64 più il buffer originale, che funziona su ogni dispositivo moderno. Per file più grandi, le alternative standard sono base64 da riga di comando su macOS/Linux (base64 -i input.bin -o output.txt), il modulo base64 di Python, o Buffer.from(data).toString('base64') di Node.js. Questo strumento non gestisce: Base64 in streaming (codifica file-per-chunk per file più grandi della memoria); la variante URL-safe in questa versione (pianificata); né la codifica MIME quoted-printable (uno schema RFC 2045 diverso per contenuto di testo email).

Privacy: perché il solo-browser conta

Base64 non è crittografia, ma i dati codificati sono spesso sensibili: chiavi API che stai incorporando in un file di config, certificati che stai codificando per il trasporto, screenshot interni che stai incorporando come URI data nella documentazione, o ricevute PDF che stai codificando per un cliente. Gli encoder lato server vedono il tuo input. Questo strumento gira interamente nel tuo browser tramite JavaScript, verifica nel tab Network di DevTools mentre clicchi Codifica, o porta la pagina offline (modalità aereo) dopo che si carica e lo strumento funziona ancora. Sicuro per codificare credenziali API, screenshot PII, documenti interni o qualsiasi dato che non vorresti copiato sull'hard drive di uno sconosciuto.

Domande frequenti

Base64 è sicuro?

No. Base64 è codifica, non crittografia. Chiunque può decodificare una stringa Base64. Non usare mai Base64 per proteggere dati sensibili, usa una crittografia adeguata (AES, RSA) per la sicurezza.

Perché Base64 rende i file più grandi?

La codifica Base64 aumenta la dimensione dei dati di circa il 33%. Tre byte di dati binari diventano quattro caratteri Base64. Questo overhead è il compromesso per poter trasmettere dati binari come testo.

Posso codificare file?

Sì! Trascina e rilascia qualsiasi file sul codificatore, o clicca per sfogliare. Il file verrà convertito in un data URI Base64 che puoi incollare direttamente in HTML, CSS o JavaScript.

Qual è la differenza tra Base64 e Base64URL?

Due caratteri. Base64 standard (RFC 4648 §4) usa + e / come 62° e 63° carattere dell'alfabeto. Base64URL URL-safe (RFC 4648 §5) usa - e _ invece, quindi la stringa codificata si inserisce direttamente negli URL senza percent-encoding. JWT, OAuth, WebAuthn e la maggior parte delle API web moderne usano Base64URL. Questo strumento attualmente emette Base64 standard; URL-safe è nella lista delle feature future. Per convertire da standard a URL-safe a mano: sostituisci + con -, / con _, opzionalmente rimuovi il padding finale =.

Perché il mio testo Unicode fallisce in alcuni strumenti Base64?

Perché la funzione legacy btoa() di JavaScript funziona solo su stringhe di byte Latin-1, chiamare btoa('é') lancia InvalidCharacterError. Molti vecchi encoder basati su browser usano btoa direttamente senza il passo di conversione UTF-8, quindi qualsiasi input non-ASCII si rompe. Il codice moderno (e questo strumento) codifica le stringhe tramite TextEncoder prima, producendo una sequenza di byte UTF-8 che btoa può quindi codificare in sicurezza. Il più recente metodo integrato Uint8Array.toBase64() gestisce UTF-8 nativamente ma non è ancora baseline su tutti i browser.

I miei dati vengono caricati?

No. La codifica e decodifica girano interamente nel tuo browser tramite JavaScript. Testo e file non attraversano mai la rete, verifica nel tab Network di DevTools mentre clicchi Codifica, o porta la pagina offline (modalità aereo) dopo che si carica e lo strumento funziona ancora. Sicuro per credenziali API, screenshot con PII, file di config interni o qualsiasi dato che non vorresti copiato sull'hard drive di uno sconosciuto.

Strumenti correlati