Mail transport was specified for 7-bit US-ASCII: printable characters, short lines, and no guarantee that the eighth bit of a byte would survive the trip. Some relays stripped it, some used it for their own purposes. A photograph, whose bytes take every value there is, could not be sent through that.
MIME solved this in 1992 without changing a single mail server, by keeping the channel textual and rewriting everything else to fit. That decision is why attachments work, and it is why they are bigger in the message than on your disk.
What a message with an attachment looks like
One text file. At the top the headers, and among them Content-Type: multipart/mixed; boundary="--=_a9f3". The boundary is an invented string that does not appear in any of the content, and every part begins with a line containing it. The last one is marked with two trailing dashes, which is how the reader knows the message has ended.
Each part then carries its own small set of headers — a Content-Type, often a Content-Disposition giving the filename, and a Content-Transfer-Encoding saying how the part was rewritten.
Parts nest. multipart/alternative holds the same message twice, plain text and HTML, and the client picks one. multipart/related holds an HTML part together with the images it refers to. So an ordinary marketing message with a logo and a PDF is three levels deep: mixed, containing related, containing alternative, containing the two versions of the text you actually wrote.
Base64, and the exact 33.3%
Base64 uses sixty-four characters that survive anything — A–Z, a–z, 0–9, + and /. Sixty-four values is six bits per character.
So it takes three bytes, which is 24 bits, and cuts them into four groups of six. Three bytes in, four characters out. That is the whole mechanism, and the increase is exactly a third — 33.3%, not approximately.
Then the lines are wrapped at 76 characters, because mail transport dislikes long ones, and each break costs a byte or two more.
Which gives the number in the title. A 4 MB file becomes 5.33 MB of base64; the line breaks take it to about 5.4; and the headers, the boundaries and whatever you typed in the body sit on top of that.
Quoted-printable, and why Arabic costs more than a photograph
Base64 is unreadable, which is a waste for a part that is nearly all ordinary text. So there is a second encoding for that case.
Quoted-printable leaves safe characters exactly as they are and writes anything else as = followed by two hexadecimal digits. An English paragraph passes through almost untouched. That is the design, and it works.
The catch is that it charges three characters per byte, not per character. In UTF-8 an Arabic or Greek letter is two bytes, so it costs six characters; an accented Latin letter is two bytes and costs six; an emoji is four bytes and costs twelve.
A plain-text body in Arabic can therefore come out three times its original size, while a JPEG next to it in the same message grows by only a third. This is the reverse of what people expect, and it is why a client sending non-Latin text usually picks base64 for the text part too — a third is cheaper than three times.
Two details worth recognising when you look at a raw message. A line ending in a lone = is a soft line break: the encoder wrapped a long line and that mark means it continues. And =3D is a literal equals sign, escaped so it is not read as the start of a code.
The other values
7bit is the default and means the part needed nothing done to it. 8bit and binary mean it was left alone despite containing bytes that older transport cannot carry. Modern servers largely support the extension that allows this, but a message may still cross a hop that does not, and then something has to re-encode it in transit. Clients keep encoding for that reason.
Why 25 MB is not 25 MB
A provider's attachment limit is a limit on the message as it travels, and the message as it travels is the encoded one.
So work backwards. 25 ÷ 1.33 is 18.75. Subtract the line breaks, the part headers, the boundaries and the text of the message itself, and the real ceiling is around 18 MB of actual file. Attach four files rather than one and it drops a little further, since each part carries its own overhead.
The receiving server has its own limit too, and the smaller of the two wins. A message can leave successfully and be refused at the far end, which is what a delivery failure about size usually turns out to be.
Why the client cannot compress it for you
The obvious fix is for your mail program to compress the attachment and the recipient's to expand it. Mail has no agreed mechanism for that. The only transformation the format defines is the transfer encoding, and every value it can take leaves the part the same size or larger.
There is also nothing to gain in the common cases. A JPEG, an MP4, a PDF and every modern Office file are already compressed — a Word document is a zip with a different extension — so zipping them saves a percent or two and costs the recipient a step.
Where compression does help, which is plain text, CSV, XML and logs, doing it by hand is worth it. Just note that the zip is base64-encoded like anything else, so a third comes back on top of whatever you saved.
Seeing it yourself
Open an .eml in a text editor and you can read the whole structure: the boundaries, the part headers, and the wall of base64 that used to be a photograph.
For the practical version, pulling the attachments out decodes the base64 and gives you the original files back, byte for byte — nothing is opened or rendered on the way. A viewer shows the same structure as a list, and taking the text out drops the markup and the quoted-printable escapes along with it.
The short version
Mail carries text, so binary is rewritten as text. Base64 turns 3 bytes into 4 characters — exactly 33.3% more, plus a line break every 76 characters — which is why 4 MB arrives as 5.4 MB and why a 25 MB limit is really about 18 MB of file. Quoted-printable is cheaper for English and much more expensive for everything else. And the file the recipient saves is identical to the one you attached, which is the point of the whole arrangement.