Why an Attachment Can Grow During Email Encoding

The file size is only the starting point

An attachment is not sent as a bare file. Email systems package it into a message, using a format that can carry text, attachments, and their associated information together. Binary files are often encoded into text-safe characters for transport. That encoding represents the original data in a form suitable for the message, but takes more space than the original bytes.

For common Base64 encoding, the encoded data is roughly one-third larger than the original, before other message overhead is counted. This is an approximation, not a prediction of the final message size. Line breaks, message formatting, headers, and the body can add more. Multiple attachments contribute to the same message, too.

Why a limit can surprise you

The size shown by a file manager or attachment picker usually describes the local file, not the complete outgoing message. A recipient’s limit may apply to the whole message as received, rather than to each attachment separately. The sending system may also enforce its own limit. Either limit can cause rejection, and you may not know the recipient’s exact rules in advance.

For example, a document that appears to be just under a stated attachment allowance may grow during encoding. Add a short message body or another file, and the complete message can cross a limit. The same file might be accepted by one recipient and rejected by another because their systems apply different limits. A file type being familiar or small does not guarantee acceptance.

Read the bounce before changing the file

A bounce, also called a nondelivery notice, is the best place to start. Look for wording that says the message or attachment was too large, a maximum size was exceeded, or delivery was rejected by the recipient’s system. The notice may identify a limit or distinguish a sending-side rejection from a recipient-side rejection. Save the notice while troubleshooting; paraphrasing it from memory can lose useful details.

If the notice does not mention size, do not assume encoding is the cause. Check whether it names a different delivery problem or asks you to correct an address or message detail. If the explanation is unclear, contact your mail provider or the recipient through another appropriate channel and ask what limit or policy applies. Avoid repeatedly resending the same oversized message, since it is unlikely to change the result.

A quick check before you try again

Compare the local size of all attachments with the limit stated in the bounce, if one is given. Remember that the comparison is approximate: encoded message size includes more than the files themselves, and a limit may refer to the entire message. If there is no stated limit, check the recipient’s guidance or ask them rather than relying on a guessed threshold.

If the recipient has asked for a particular method, follow that instruction. Otherwise, ask which sharing method they can access and are permitted to use. A link-based option may avoid attaching the full file to email, but access rules, account requirements, file restrictions, and expiration settings can vary. Do not assume that a particular service, link, or file type will be accepted.

• Read the bounce and note whether it identifies message size or another cause.
• Check the combined attachment sizes, not just the largest file.
• Ask the recipient which sharing method they approve if the message remains too large.
• After changing the approach, confirm receipt with the recipient when the file is important.

A practical example

Suppose you send a project document and several images. The files appear to fit the allowance you expected, but a bounce says the message exceeded the recipient’s maximum size. The notice indicates a message-level limit, so the total includes encoding and the email itself—not just the sizes shown on your device.

To: [recipient] <editor@example.com>
From: [sender] <alex@example.com>
Subject: Project files

The message was rejected for exceeding the recipient’s size limit.

Next step: Ask the recipient which approved sharing method to use, then send access details and confirm they can open the files.

Confirm the new approach worked

A sent message or a successfully created sharing link does not prove the recipient received or can open the material. Check for a delivery failure after resending, and follow up through a suitable channel if you need confirmation. For a shared file, verify that the recipient has the required access and that the link points to the intended item. Respect the recipient’s security and handling requirements, especially for confidential material.

The useful distinction is simple: local file size describes the file; the receiving system may judge the larger, packaged email. When a size-related bounce confirms that mismatch, use its details to guide the next step instead of repeatedly attaching the same files.