Nel 2026 l’email continua a essere uno degli strumenti di comunicazione più usati in assoluto e, soprattutto in ambito aziendale, resta difficile sostituirla davvero. Chat, piattaforme collaborative e sistemi di messaggistica istantanea hanno conquistato una parte importante delle comunicazioni quotidiane, ma quando bisogna inviare un documento, formalizzare una richiesta, conservare una traccia verificabile dello scambio o raggiungere interlocutori appartenenti a organizzazioni diverse, la posta elettronica mantiene un ruolo centrale.
Proprio perché utilizziamo continuamente l’email, alcuni suoi comportamenti finiscono per sembrare quasi inspiegabili. Uno dei più evidenti? Quando si allega un file piuttosto pesante, ad esempio uno da 20 MB, il messaggio può occupare quasi 30 MB durante il trasferimento tra i server di posta.
I limiti nella dimensione degli allegati applicati dai provider email
La questione diventa particolarmente importante perché i provider impongono limiti abbastanza rigidi alla dimensione degli allegati.
Nei servizi più diffusi, la soglia si colloca spesso nell’ordine dei 20-25 MB: Gmail personale consente fino a 25 MB complessivi di allegati; Outlook.com indica anch’esso un limite di 25 MB; Yahoo Mail fissa a 25 MB la somma degli allegati presenti nel singolo messaggio. In ambito aziendale le soglie possono invece essere differenti, perché sistemi come Google Workspace o Microsoft Exchange permettono agli amministratori di applicare policy specifiche.
Ed è qui che nasce un equivoco frequente: il limite dichiarato dal servizio non va interpretato automaticamente come “posso prendere un file che sul disco pesa esattamente 25 MB e allegarlo senza problemi“. Durante la costruzione del messaggio il contenuto binario dell’allegato deve infatti essere codificato e inserito nella struttura MIME (ne parliamo tra poco); con la tradizionale codifica Base64, la sola rappresentazione dell’allegato cresce di circa un terzo, a cui si aggiungono ritorni a capo, intestazioni, delimitatori e le altre parti dell’email.
Il file originale non cambia dimensione: è la sua rappresentazione all’interno del messaggio di posta a occupare più spazio. Per capire perché accade bisogna quindi vedere cosa fanno Base64 e MIME e, soprattutto, perché tecnologie nate decenni fa continuano ancora oggi a incidere sulla quantità di dati trasferiti quando premiamo il pulsante Invia.
Perché esiste la codifica Base64
Per capire perché un’email con uno o più allegati cresce in dimensioni più della somma degli allegati stessi, bisogna spiegare brevemente la struttura di un messaggio email.
I protocolli di posta elettronica hanno radici in sistemi progettati per trasferire sequenze di caratteri. Inviare direttamente qualsiasi possibile valore binario, da 00 a FF in esadecimale, non era sempre sicuro: alcuni componenti intermedi avrebbero potuto interpretare determinati byte come caratteri di controllo, fine riga o elementi con un significato speciale.
Lo standard MIME (Multipurpose Internet Mail Extensions) ha permesso di descrivere all’interno della stessa email contenuti diversi: testo semplice, HTML, immagini, documenti, audio e in generale allegati di qualunque tipo. Nella definizione MIME dell’email potrebbero comparire, in forma semplificata, intestazioni simili alle seguenti:
Content-Type: application/pdf; name="documento.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="documento.pdf"
Dopo queste informazioni, compare il contenuto del file trasformato in Base64. Lo standard Base64 usa un insieme di caratteri stampabili e rappresenta gruppi di 24 bit in ingresso come quattro gruppi da 6 bit. Qui compare il primo aumento di dimensione.

Come si verifica l’aumento di dimensione per via della codifica
Supponiamo di avere esattamente un file da 20 MB: trascurando per il momento tutto il resto, la sua dimensione dopo l’applicazione della codifica Base64 diventa la seguente:
20.000.000 × 4 / 3 = 26.666.667 byte
Il file che occupava 20 MB diventa quindi circa 26,7 MB soltanto per effetto della codifica. L’aumento è quindi di 6,7 MB, pari a circa il +33,3%.
La codifica prende i dati originali a gruppi di 3 byte, cioè 24 bit complessivi, e li suddivide in 4 gruppi da 6 bit. Ciascun gruppo da 6 bit viene poi rappresentato con un carattere dell’alfabeto Base64 (per 3 byte originali servono 4 caratteri Base64). Per stimare la dimensione codificata basta quindi moltiplicare la dimensione originale per il rapporto 4/3.
Base64 non è una forma di compressione. In realtà fa esattamente il contrario dal punto di vista dello spazio occupato: sacrifica compattezza in cambio della possibilità di rappresentare qualsiasi sequenza binaria usando un insieme limitato di caratteri.
Non importa neppure se l’allegato sia già molto compresso. Un’immagine JPEG, un MP4, un file ZIP o un archivio 7z subiscono lo stesso rapporto di espansione Base64.
Dal +33% del Base64 a quasi 30 MB: entrano in gioco MIME e MiB
I circa 26,7 MB ottenuti dalla codifica Base64 nel caso del nostro ipotetico allegato da 20 MB non rappresentano ancora la dimensione finale del contenuto trasmesso.
Nel formato MIME, infatti, il flusso Base64 è normalmente suddiviso in righe da non più di 76 caratteri, come previsto dallo standard (RFC 2045), e ogni riga termina con la sequenza CRLF, cioè \r\n, che occupa altri due byte.
Nel nostro esempio, circa 26,7 milioni di caratteri Base64 producono all’incirca 350.877 righe e quindi altri 0,7 MB di ritorni a capo: l’allegato originario da 20 MB arriva così a circa 27,37 MB.
L’overhead complessivo della rappresentazione Base64 MIME non è quindi soltanto del 33,3%: considerando anche la suddivisione delle righe, si avvicina al 36,8%, valore ottenibile approssimativamente con 4 / 3 × 78 / 76.
C’è poi un’altra possibile fonte di confusione: un file indicato genericamente come pesante 20 MB, può in realtà occupare 20 MiB (mebibyte) cioè 20.971.520 byte.
MB e MiB non indicano la stessa quantità di dati: un MB decimale corrisponde a 1.000.000 di byte, mentre un MiB ne contiene 1.048.576, perché utilizza multipli binari di 1024. Di conseguenza, 20 MiB equivalgono a: 20 × 1.048.576 = 20.971.520 byte
In questo caso la sola codifica Base64 porta il contenuto a circa 27,96 milioni di byte e, aggiungendo i ritorni a capo MIME, si arriva intorno a 28,7 MB decimali, ancora prima di conteggiare intestazioni, boundary (stringhe usate per separare le diverse parti del contenuto MIME) e le altre sezioni del messaggio.
Ecco perché dire che un allegato da 20 MB può trasformarsi in un’email vicina ai 30 MB non è affatto un’esagerazione.

MB o MiB? La confusione nasce anche da Windows
Una parte della confusione dipende anche da come Windows ed Esplora file mostrano le dimensioni di file e cartelle.
Nelle proprietà di un file, infatti, Windows usa normalmente sigle come KB, MB e GB, ma i valori sono calcolati con multipli binari di 1024: ciò che viene indicato come 20 MB corrisponde quindi, di fatto, a circa 20 MiB, ossia 20.971.520 byte.
Lo stesso comportamento spiega perché un SSD commercializzato come 1 TB venga mostrato da Windows con una capacità di circa 931 GB: il produttore considera 1 TB pari a 1.000.000.000.000 di byte, mentre Windows divide quel valore per 1.073.741.824, cioè il numero di byte contenuti in un GiB, continuando però a utilizzare l’etichetta “GB”.
Quando si confrontano dimensioni di file, allegati e limiti imposti dai provider email, è quindi importante capire se si stanno usando unità decimali o binarie.
Perché continuiamo a usare Base64 se oggi Internet trasporta dati binari?
Internet trasferisce continuamente gigabyte di file binari tramite HTTP, quindi perché trasformare ancora gli allegati email in testo? La risposta è soprattutto nella compatibilità end-to-end.
SMTP si è evoluto e dispone di estensioni che consentono capacità maggiori rispetto al protocollo originario. Tuttavia, un messaggio email può attraversare server, gateway, filtri, sistemi di sicurezza, appliance e software differenti.
La codifica Base64 costituisce una rappresentazione estremamente prevedibile: lettere, numeri e pochi caratteri speciali. Riduce drasticamente il rischio che qualche componente lungo il percorso interpreti male i dati binari. L’inefficienza in termini di dimensione è il prezzo pagato per una soluzione robusta e compatibile con decenni di infrastruttura email.
Le immagini nella firma possono essere piccoli allegati MIME
Anche ciò che visivamente non sembra un allegato può contribuire alla dimensione del messaggio. Una firma HTML, ad esempio, può contenere un logo incorporato direttamente nell’email. L’immagine può essere inserita come parte MIME con un suo specifico Content-ID:
Content-ID: <logo123>
Content-Transfer-Encoding: base64
L’HTML può quindi richiamarla usando qualcosa del tipo:
<img src="cid:logo123">
Anche quell’immagine viene codificata in Base64 e aggiunge, a sua volta, ulteriore overhead. Con file da pochi kilobyte la differenza è trascurabile; con molte immagini incorporate, firme complesse o messaggi inoltrati ripetutamente, il peso può però diventare significativo.
Allegare un file non equivale a caricarlo su un server e mandare un link
È importante distinguere due modalità che, nell’interfaccia grafica, possono apparire molto simili.
Con un vero allegato MIME, il contenuto del file entra fisicamente nel messaggio: il destinatario riceve quindi la rappresentazione codificata del documento insieme all’email.
Con servizi che caricano invece il file su uno spazio cloud e inseriscono nel messaggio soltanto un collegamento, la situazione cambia completamente. In questo caso specifico, l’email può contenere soltanto poche centinaia di byte aggiuntivi, corrispondenti all’URL da cui scaricare il file.
Il file da 20 MB o più viaggia in questo caso attraverso HTTP o un protocollo analogo quando il destinatario decide di scaricarlo; non deve essere trasformato in un enorme blocco Base64 all’interno del messaggio email.
È anche uno dei motivi per cui i servizi di posta tendono a proporre il caricamento sul cloud quando gli allegati hanno dimensioni importanti e superano i limiti imposti per la dimensione degli allegati stessi.