How do attachments work in email?

Email was originally built to carry plain text. Just text. That's it. So when people started wanting to send files like PDFs, images, or spreadsheets, the whole system had to be extended to make that possible. That extension is called MIME, and it's what makes attachments work today.

Here's the core problem MIME solves. Files like images or PDFs are binary data, meaning they contain bytes that don't map to readable characters. Email systems were only designed to handle ASCII text, so sending raw binary data through them would corrupt the file completely. MIME's solution is to convert the binary content into plain ASCII characters using an encoding scheme called Base64. Think of it like translating a foreign language into one the postal system can read, then translating it back when it arrives.

When you attach a file to an email, your email client does a few things automatically. It wraps the entire message in a multipart/mixed MIME structure, which is basically a container that can hold multiple separate pieces. One piece is your message body. Each attachment is another piece. Every piece has its own small set of headers that describe what it is and how to handle it.

Those headers for an attachment look something like this:

• Content-Type: application/pdf; name="report.pdf" tells the receiving client what kind of file it is.
• Content-Transfer-Encoding: base64 tells it that the content has been Base64 encoded and needs to be decoded.
• Content-Disposition: attachment; filename="report.pdf" tells the client to offer this as a download rather than trying to display it inline.

After those headers comes a wall of Base64-encoded text that looks like complete gibberish. Your email client reads those headers, takes that gibberish, decodes it back into the original binary file, and presents it to you as a normal downloadable file. You never see the encoded version.

And one practical side effect worth knowing: Base64 encoding inflates file size by about 33%. So a 1MB PDF becomes roughly 1.33MB inside the email. That adds up quickly if you're attaching multiple files, and it's a big reason why most providers (including Gmail and Outlook) cap attachments somewhere between 10MB and 25MB total.

There's also a difference between attachment and inline display. The Content-Disposition header controls this. Set it to inline and the client tries to render the content directly inside the message (you see this with embedded images). Set it to attachment and the client asks you to download it instead. Images in HTML emails are usually set to inline. Documents almost always go to attachment.

If you're sending large files as part of a marketing or transactional email, skip the attachment entirely and share a cloud link instead (Google Drive, Dropbox, that kind of thing). Beyond the size limits, attachments in bulk email can hurt your deliverability, especially with file types that security filters treat as suspicious.