Codificatore Base64 di file gratuito
Converti qualsiasi file in un URL dati Base64 · tutto resta nel tuo browser.
Trascina e rilascia un file qui
o
Seleziona o rilascia un file da codificare.
Come funziona
- Carica il tuo file: rilascia qualsiasi file, immagine, PDF, font, audio o binario, nella zona di rilascio o clicca per sfogliare.
- Ottieni la stringa Base64: Il file viene letto e codificato in Base64 istantaneamente nel tuo browser.
- Copia e usa: Copia la stringa Base64 per incorporarla in HTML, CSS, payload JSON, URI dati o qualsiasi formato testuale.
Perché usare il codificatore Base64 di file?
I file binari non possono essere incorporati direttamente in formati testuali come HTML, CSS, JSON o XML. La codifica Base64 converte qualsiasi file binario in una stringa ASCII sicura che può essere incorporata ovunque sia consentito il testo. Questo è essenziale per incorporare immagini direttamente nell’HTML (URI dati), includere font nel CSS, inviare file tramite API email o JSON senza endpoint di caricamento e creare documenti HTML autonomi.
Funzionalità
- Qualsiasi tipo di file: Codifica immagini, PDF, font, audio, video e tutti i file binari.
- Output URI dati: Attiva per ottenere un URI dati pronto all’uso per l’incorporamento diretto.
- Visualizzazione dimensione file: Mostra le dimensioni originali e codificate per conoscere l’overhead.
- Elaborazione locale: i file vengono letti e codificati interamente nel tuo browser, nulla viene caricato.
Domande frequenti
Quanto è più grande il Base64 rispetto al file originale?
La codifica Base64 aumenta la dimensione del file di circa il 33 %. Un’immagine di 100 KB diventa circa 133 KB quando codificata in Base64. Questo overhead è il compromesso per poter incorporare contenuti binari nel testo.
Posso usare immagini Base64 in HTML?
Sì. Usa un URI dati come <img src="data:image/png;base64,[tuo-base64]">. Questo incorpora l’immagine direttamente nell’HTML senza richieste HTTP esterne, anche se aumenta la dimensione della pagina.
C’è un limite di dimensione del file?
Lo strumento non ha limiti imposti, ma file molto grandi (oltre 10 MB) possono essere lenti da codificare e la stringa risultante sarà estremamente lunga. Per file di grandi dimensioni, considera una soluzione lato server.
Da dove viene Base64, e perché lo usiamo ancora
Base64 è stato progettato per trasportare dati binari a 8 bit attraverso canali ASCII a 7 bit. La prima specifica formale è stata RFC 989 (febbraio 1987) per Privacy-Enhanced Mail. RFC 1341 (giugno 1992) e soprattutto RFC 2045 «MIME Parte Uno» (novembre 1996) l'hanno reso il modo standard per allegare file binari alle email. Il documento canonico attuale è RFC 4648 (ottobre 2006), che ha anche definito la variante URL-safe. La meccanica è semplice: prendere 3 byte di input (24 bit), dividere in quattro gruppi di 6 bit, cercare ciascuno nell'alfabeto di 64 caratteri A-Z a-z 0-9 + /, aggiungere il padding = per rendere la lunghezza dell'output un multiplo di 4. La dimensione di output è esattamente 4 ÷ 3 ≈ 133 % dell'input. Per l'incorporamento negli URL (JWT, OAuth, URL S3 pre-firmati), la variante URL-safe di RFC 4648 §5 sostituisce - per + e _ per /; il padding è tipicamente omesso.
L'URL data:: Base64 nei tuoi HTML e CSS
Lo schema URL data: è stato specificato in RFC 2397 (agosto 1998). Formato: data:[<mediatype>][;base64],<data>. Esempio: <img src="data:image/png;base64,iVBORw0KGgo..."> incorpora un PNG inline senza richiesta HTTP aggiuntiva. Il WHATWG URL Living Standard governa come i browser moderni interpretano questi URL e l'HTML Living Standard conferma che sono validi ovunque sia consentito un URL, incluso <img>, <link>, <iframe>, e la funzione CSS url(). Guida pratica: usa gli URL data per asset inferiori a circa 4 KB, dove risparmiare una richiesta HTTP supera il 33 percento di gonfiore del payload. Oltre 10 KB, i riferimenti a file regolari con caching del browser vincono quasi sempre, specialmente su multiplexing HTTP/2.
API del browser che alimentano questo strumento
Questa pagina utilizza l'API FileReader dall'HTML Living Standard (originariamente W3C File API First Public Working Draft novembre 2009; spedito in Chrome 13 / Firefox 3.6 / Safari 6 / Internet Explorer 10). FileReader.readAsDataURL(blob) restituisce la stringa completa data:<mime>;base64,<...> con una sola chiamata. L'alternativa legacy è btoa() (chiamata così per il comando storico Unix «binary-to-ASCII» e un residuo di JavaScript DOM Level 0), ma lancia su input non-Latin-1 a meno che non si transcodifichi prima attraverso UTF-8. Il rimpiazzo moderno è Uint8Array.prototype.toBase64(), aggiunto a ECMAScript 2025 in TC39 Stage 4. È stato spedito in Chrome 132 (gennaio 2025), Firefox 133 (novembre 2024), e Safari 18.2 (dicembre 2024). Usa la nuova API per ogni nuovo codice; riserva btoa per la compatibilità con browser più vecchi.
Dove va davvero l'output di questo strumento
- Icone inline e piccole immagini in HTML / CSS per documenti autocontenuti o offline-first.
- Payload di upload file JSON quando il backend si aspetta una stringa Base64 in un campo JSON invece di
multipart/form-data. - Allegati email MIME: RFC 2045 richiede Base64 (o quoted-printable) per ogni corpo non-7-bit, il che significa ogni allegato PDF, immagine o documento.
- Token JWT / OAuth: ogni JWT è tre segmenti Base64 URL-safe uniti da
.. - Fixture di test committate in git, così le immagini di test / documenti di esempio viaggiano con il file di test.
- Payload Web Push quando si consegna un blob binario attraverso l'API Push.
- Web font del critical path incorporati in CSS per evitare FOIT (flash of invisible text) al primo rendering, trade-off accettato.
Errori comuni
- Trattare Base64 come crittografia. Base64 è codifica, non sicurezza. Chiunque abbia la stringa può decodificarla nel proprio browser. Non usare mai Base64 per «nascondere» credenziali, chiavi API o PII.
- Dimenticare il prefisso
data:<mime>;base64,. Una stringa Base64 nuda non è un URL data. Un<img>ha bisogno della forma completadata:image/png;base64,<il-tuo-base64>per renderizzare. - Mescolare Base64 URL-safe e standard. JWT e URL S3 pre-firmati usano URL-safe (
-e_). Incollare Base64 standard (+e/) in questi contesti produce fallimenti di decodifica silenziosi. - Dimenticare la direttiva CSP
data:. Una pagina conimg-src 'self'nella sua Content Security Policy rifiuterà di caricare qualsiasi URLdata:image/.... Devi consentire esplicitamenteimg-src 'self' data:(e similmente perfont-src,media-src, ecc.). - Codificare file da 100 MB in modo sincrono sul thread principale.
FileReader.readAsDataURLblocca l'UI per diversi secondi su un file di 200 MB. Per qualsiasi cosa oltre ~20 MB, usa un Web Worker o chunk di stream. - Chiamare
btoa("é")direttamente. LanciaInvalidCharacterErrorperchébtoasi aspetta Latin-1, non UTF-8. O usabtoa(unescape(encodeURIComponent(text)))(legacy), o passa unUint8Arrayattraverso il metodo modernotoBase64(). - Inserire un logo da 500 KB come URL data. Il gonfiore del 33 percento più la perdita del caching del browser significa che ogni caricamento di pagina scarica 665 KB invece di 500 KB-una-volta. Usa un riferimento asset regolare.
Altre domande frequenti
Qual è l'overhead esatto di dimensione di Base64?
Esattamente 4 ÷ 3 ≈ 1,333× l'input, più 1-2 byte di padding =. Un input di 999 byte diventa 1332 caratteri di Base64 (nessun padding perché 999 ÷ 3 = 333 esattamente). Un input di 1000 byte diventa 1336 (un byte di padding). Per un URL data, aggiungi i byte del prefisso (es. data:image/png;base64, sono 23 caratteri).
Come ottengo Base64 URL-safe per JWT o URL S3 pre-firmati?
Prendi l'output Base64 standard da questo strumento e applica due sostituzioni: + → -, / → _. JWT specificamente rimuove il padding = finale; S3 lo mantiene. RFC 4648 §5 documenta la variante.
Posso fare round-trip di un file attraverso Base64 senza corruzione?
Sì. Base64 è una codifica lossless. Codificare in Base64 e poi decodificare di nuovo produce un originale byte-identico. L'unico modo per perdere dati è troncare la stringa Base64 (es. limitando i caratteri nel tuo storage) o confondere gli alfabeti standard vs URL-safe nella decodifica.
Qual è la dimensione massima del file che questo strumento può gestire?
Nessun limite rigido; in pratica la memoria del browser è il soffitto. Codificare un file di 100 MB richiede circa 100 MB di input più 133 MB di output, più overhead DOM per la stringa risultante, forse 400 MB in totale. Su mobile, aspettati fallimenti oltre circa 30 MB. La codifica gira sul thread principale, quindi l'UI si congela durante l'elaborazione; per file oltre 20 MB, una soluzione lato server o Web Worker è più comoda.
Il mio file viene caricato da qualche parte?
No. Il file viene letto con l'API FileReader.readAsDataURL del browser, che gira interamente nel tuo browser. Nessuna richiesta di rete viene effettuata e nessuna copia del tuo file viene memorizzata su alcun server. Apri la scheda Rete in DevTools e rilascia un file: vedrai zero richieste in uscita durante la codifica.