> base64 encoder | testo | file <

Digita o incolla il tuo testo nell'area INPUT sopra. La codifica automatica è attiva per impostazione predefinita — il risultato Base64 appare nella casella OUTPUT mentre digiti. Clicca su [ENCODE] o premi Ctrl/Cmd + Enter per avviare la codifica manualmente. Attiva --url-safe o --no-padding a seconda di dove verrà usato il Base64 (JWT, OAuth, URL → entrambi attivi). Tutto viene eseguito localmente nel tuo browser: nessun upload, nessun log, nessuna richiesta di rete legata al tuo input.

Clicca sul pulsante [upload file] sotto l'area di input e scegli un file fino a 100 MB. L'encoder lo legge con FileReader.readAsArrayBuffer, fa fluire i byte attraverso btoa in blocchi da 32 KB (così i file di grandi dimensioni non fanno crashare il browser) e scrive l'intero Base64 nella casella OUTPUT. Per file più grandi, usa un encoder da riga di comando: base64 < input.bin > output.txt (macOS/Linux), oppure PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Se vuoi il Base64 formattato come Data URI (ad es. data:image/png;base64,...), anteponi il tipo MIME e ;base64, all'output, oppure usa il nostro strumento dedicato Immagine in Base64, che produce Data URI pronti da incollare per PNG, JPG, GIF, WebP e SVG.

Tutte e tre sono definite nella RFC 4648:

• Base64 standard (§4) usa l'alfabeto A-Z a-z 0-9 + / con padding =. La lunghezza dell'output è sempre un multiplo di 4. Sicuro per MIME, HTTP Basic Auth e valori di stringa JSON.

• Base64 URL-safe (§5) sostituisce + con - e / con _. Necessario quando il Base64 viene inserito in percorsi URL, parametri di query, nomi di file o segmenti JWT — i caratteri standard +/ richiederebbero altrimenti la codifica percentuale.

• Senza padding (sia §4 che §5, base64url senza padding) elimina i caratteri = finali. La lunghezza non è più un multiplo di 4, ma i decoder possono calcolare la lunghezza originale dal resto modulo 4. Usato da JWT (base64url secondo la RFC 7515), WebAuthn e alcune implementazioni CBOR/COSE.

Ai decoder va indicato quale variante aspettarsi — il nostro Decoder Base64 le rileva automaticamente tutte e tre.

Ogni linguaggio e runtime importante include la codifica Base64. Snippet pronti da copiare e incollare:

JavaScript (browser):
btoa('Hello') // SGVsbG8=
// Per UTF-8:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // sicuro UTF-8

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-safe, senza padding

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-safe senza padding

PHP: base64_encode('Hello')
Ruby: Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go: base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...) (senza padding)
Java: Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#: Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust: base64::engine::general_purpose::STANDARD.encode("Hello")

Shell (macOS/Linux): echo -n 'Hello' | base64 → SGVsbG8=. Usa base64 -w 0 su Linux per sopprimere l'a capo a 76 colonne.

L'output Base64 è ~33% più grande dell'input: ogni 3 byte di input diventano 4 caratteri di output. Formula esatta: ceil(n / 3) × 4 incluso il padding, oppure ceil(n × 4 / 3) senza. Più qualche byte di overhead aggiuntivo se vai a capo a 76 colonne (MIME) o 64 colonne (PEM).

Esempi:
• 1 KB binario → ~1,37 KB Base64
• 100 KB immagine → ~137 KB Data URI
• 1 MB PDF → ~1,37 MB Base64 in JSON

Quando evitare Base64:
• Trasferimenti di file di grandi dimensioni: un'immagine da 10 MB incorporata come Base64 in HTML diventa 13,7 MB di testo analizzato, blocca il thread principale e non può essere memorizzata nella cache separatamente. Preferisci <img src="/assets/photo.png">.
• API critiche per le prestazioni: un payload Base64 da 500 KB in JSON viene analizzato ~2-3× più lentamente di un endpoint binario equivalente.
• Come misura di sicurezza: Base64 non è crittografia — chiunque può decodificarlo. Usa AES-GCM o simili per la riservatezza.
• BLOB di database: archivia i byte grezzi come BLOB/BYTEA, non come testo Base64, per risparmiare il 33% di spazio ed evitare i round trip di codifica/decodifica.

JWT (RFC 7515) e OAuth PKCE (RFC 7636) usano entrambi il Base64 URL-safe senza padding, spesso chiamato base64url. Per produrlo con questo strumento: attiva entrambe le caselle --url-safe e --no-padding, quindi codifica il tuo testo.

Equivalenti programmatici:
• JavaScript: btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js: Buffer.from(s).toString('base64url')
• Python: base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go: base64.RawURLEncoding.EncodeToString([]byte(s))
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

Campi JWT comuni che richiedono base64url: i tre segmenti separati da punti (header, payload, firma), code_verifier/code_challenge di OAuth PKCE, le challenge WebAuthn, le chiavi Web Push p256dh/auth e i parametri Request.state di Google.

Un bug comune è inviare un JWT con Base64 standard (+/) — le API lo rifiutano come malformato perché il + viene decodificato come URL in uno spazio durante il transito.

Sì, con un'avvertenza. Questo encoder produce la parte Base64 di un Data URI — la parte dopo ;base64,. Per costruire un Data URI completo, anteponi:

data:<mime-type>;base64,<encoded-output>

Tipi MIME comuni:
• data:image/png;base64,... — immagine PNG
• data:image/jpeg;base64,... — immagine JPEG
• data:image/svg+xml;base64,... — SVG (oppure usa data:image/svg+xml;utf8, senza Base64 — di solito più piccolo)
• data:application/pdf;base64,... — file PDF
• data:application/font-woff2;base64,... — incorporamento di font
• data:text/plain;charset=utf-8;base64,... — testo racchiuso in Base64

Per immagini e SVG, lo strumento Immagine in Base64 emette il Data URI completo pronto da incollare in CSS background-image, inline <img src="..."> o tag <object data="...">.

Avviso sulle dimensioni: i Data URI superiori a 20-30 KB peggiorano l'LCP (Largest Contentful Paint) perché il browser non può precaricarli — mantieni piccole le immagini Base64 inline e preferisci il normale <img> con loading="lazy" per gli asset più grandi.

Sì — niente lascia il tuo browser. L'encoder viene eseguito interamente in JavaScript usando le API native btoa(), TextEncoder e FileReader. Non ci sono chiamate di rete sul contenuto dell'input, nessuna telemetria, nessun logging, nessuna analisi di terze parti su ciò che codifichi. Puoi aprire la scheda Network in DevTools durante la codifica e osservare zero richieste correlate.

Tuttavia, Base64 non è crittografia — è una codifica reversibile e chiunque abbia l'output può decodificarlo. Quindi:
• Non incollare segreti di produzione in chat, screenshot o log, nemmeno in forma codificata.
• Per HTTP Basic Auth, l'header Base64 Authorization: Basic è sicuro solo su TLS (HTTPS). Su HTTP in chiaro è banalmente intercettabile.
• Per una vera riservatezza, usa AES-GCM, age, sops o un KMS — poi codifica in Base64 il testo cifrato per il trasporto se necessario.

Per politiche rigorose di esfiltrazione dei dati, salva questa pagina offline (Cmd/Ctrl + S). L'encoder funziona completamente isolato dopo un caricamento, poiché non c'è alcuna dipendenza dal server.

L'encoder supporta file fino a 100 MB tramite il limite rigido nel gestore dei file — abbastanza grande per la maggior parte delle immagini, PDF, archivi ZIP e persino brevi video. Obiettivi di prestazione:

• < 1 MB: la codifica si completa in <50 ms, nessun blocco dell'interfaccia.
• 1 – 10 MB: 100-500 ms a seconda della CPU. Il browser rimane reattivo perché codifichiamo in blocchi da 32 KB.
• 10 – 100 MB: 2-15 secondi. L'area di testo dell'output potrebbe rallentare leggermente quando incolli/scorri stringhe Base64 così enormi. Considera di scaricare l'output come file .txt da DevTools se necessario.
• > 100 MB: bloccato — l'overhead di memoria del browser (byte di input + stringa binaria + stringa Base64 ≈ 3-4× la dimensione del file) rischia di far crashare la scheda. Usa:

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

Per flussi di lavoro in streaming/multi-GB, vedi codificare file di grandi dimensioni in Base64 per un approccio a blocchi con Node.js/Python che evita di caricare tutto in memoria.

Questo encoder usa UTF-8, la stessa codifica usata dal web moderno, JSON, Linux, macOS e quasi tutti i linguaggi di programmazione per impostazione predefinita. Dietro le quinte, il testo viene passato attraverso new TextEncoder().encode(input), che produce sempre byte UTF-8, e solo allora viene codificato in Base64.

Perché è importante: la vecchia funzione JavaScript btoa() gestisce solo Latin-1 e genera InvalidCharacterError su caratteri come é, 中 o 😀. Il nostro wrapper gestisce la conversione UTF-8 per te, così emoji, cinese, giapponese, coreano, arabo, cirillico e qualsiasi punto di codice Unicode vengono codificati correttamente.

Se hai bisogno di una codifica diversa:
• UTF-16 LE (nativo di Windows): raro — di solito è segno di interoperabilità legacy. Usa comunque new TextEncoder({ fatal: true }).encode(s) e converti a monte.
• ISO-8859-1 / Latin-1: mappa manualmente i punti di codice 0-255 sui byte prima della codifica.
• GB18030, Shift_JIS, EUC-KR: usa una libreria come iconv-lite in Node.js per transcodificare prima.

Un'insidia sottile: se i tuoi dati di origine sono già in una codifica non UTF-8 (ad es. leggendo un dump MySQL legacy), decodificali prima con il codec corretto, poi ricodificali in UTF-8 prima di applicare Base64 — altrimenti il Base64 decodificato conserverà il mojibake.