# Email attachment size limits: calculate the real message size > Understand Gmail, Outlook, Exchange, and API attachment limits; estimate base64 and MIME overhead; prevent 552 bounces; and choose secure download links for large files. - **Category:** Developer guide - **Published:** August 4, 2026 - **Reading time:** 15 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/email-attachment-size-limits](https://emailbump.com/blog/email-attachment-size-limits) An email attachment limit usually applies to the encoded message, not only to the files selected by the sender. MIME headers, HTML, plain text, inline images, boundaries, and base64 expansion all consume the same budget. A 20 MB file can become roughly 27 MB before the rest of the message is counted, so comparing raw file bytes with a 25 MB message limit is unsafe. The usable ceiling is the smallest enforced limit across your application, email API or SMTP provider, sending server, recipient server, mailbox policy, client, security gateway, and downstream forwarding route. Limits change by account and administrator policy; design for measured encoded size and a controlled fallback rather than one universal number. > **Attachment bytes are not message bytes** > > Base64 represents each three input bytes with four output characters, then MIME line wrapping and part headers add more. Measure or generate the final message when the limit matters. ## Current consumer and business examples ### Documented limits vary by product and policy ```text SERVICE / CONTEXT DOCUMENTED EXAMPLE (AUGUST 2026) Personal Gmail compose 25 MB total attachment selection; larger uses Drive Google Workspace Administrator sets send/receive attachment limits Workspace Enterprise Plus Up to 50 MB attachment send, 70 MB incoming message Outlook.com 25 MB file attachment; larger can use OneDrive Exchange Online Configurable message/client limits; defaults and paths vary Transactional email API Provider/account endpoint limit; often total request/message Check the official documentation for the exact account on the day you ship. A recipient or gateway can enforce a lower value than the sender accepts. ``` Google’s current help says personal Gmail accounts have a 25 MB attachment limit and Workspace administrators set work or school limits. Google announced 50 MB sending attachments and a 70 MB incoming-message limit for eligible Enterprise Plus customers in 2026. Microsoft documents a 25 MB Outlook.com file-attachment limit, while Exchange Online has configurable message and client limits. These are examples, not a cross-provider safe target. ## Why base64 makes attachments larger ### Base64 estimate ```text base64_characters = 4 × ceil(file_bytes / 3) Then add: - CRLF line breaks inserted into encoded data - Content-Type and Content-Disposition headers - MIME boundaries - HTML body and plain-text alternative - inline images, signatures, and tracking assets - message headers and any downstream modifications Quick planning estimate: raw files × 1.37, then add body/header safety margin. Final MIME generation is more reliable than an estimate. ``` RFC 2045 defines base64 in 24-bit groups represented by four encoded characters and limits encoded lines to no more than 76 characters. That creates the familiar four-thirds expansion plus line breaks. Multiple attachments each add their own MIME headers and boundaries. ## Worked attachment-size examples ### Approximate encoded sizes before the rest of the message ```text RAW FILES BASE64 CORE WITH LINE WRAPS (APPROX.) 1 MB 1.33 MB 1.37 MB 5 MB 6.67 MB 6.84 MB 10 MB 13.33 MB 13.68 MB 15 MB 20.00 MB 20.53 MB 20 MB 26.67 MB 27.37 MB 25 MB 33.33 MB 34.21 MB Units and exact line ending behavior matter. Add every body part and header, then compare the serialized message with every known limit on the route. ``` Do not use the table as a guarantee. A provider may define MB using decimal bytes while your application displays binary MiB; an API may base64-encode inside JSON and impose an HTTP request limit; another may accept raw MIME; a receiving gateway may transform or scan the message before applying policy. ## Set an application limit below the infrastructure maximum - Choose a product limit based on the lowest common recipient route you need to support, not the largest provider claim. - Reserve margin for HTML, text, inline images, MIME headers, encoding, provider additions, and future template growth. - Calculate on raw bytes at upload time and on serialized message bytes before submission. - Reject or switch to a link before enqueueing a message the provider cannot accept. - Display the limit and current usage near file selection using the same byte definition as the backend. - Apply lower limits to public forms, inbound attachments, fan-out sends, and resource-constrained workers when appropriate. ## API request size and message size are different limits An email API may accept attachments as base64 inside JSON. The HTTP body therefore contains encoded files plus JSON syntax and the message fields. The service may enforce an ingress request limit before it assembles MIME, followed by a separate maximum message size. Proxies, serverless platforms, application servers, and web frameworks can impose their own request-body limits first. ### Size checkpoints ```text BROWSER UPLOAD -> app ingress body limit RAW FILE STORAGE -> product file and account quota QUEUE PAYLOAD -> never duplicate giant base64 blobs when object reference works EMAIL API JSON -> provider HTTP request limit SERIALIZED MIME -> provider message limit SMTP TRANSFER -> relay and gateway policy RECIPIENT MX -> mailbox/server message limit FORWARDING -> another receiver may apply a smaller limit ``` ## Prefer secure links for large or sensitive files Store the object outside the email system, scan and authorize it, then link to an authenticated application page. This reduces message weight, allows revocation and access logging, supports updated files, and avoids duplicating sensitive data across mailboxes and forwarding chains. - Require an authenticated session for account data whenever practical. - If a signed URL is justified, scope it to one object and action, keep its lifetime short, and prevent it leaking through analytics or referrers. - Show filename, size, type, owner, and expiration on the application page before download. - Do not place private permanent object-store URLs or credentials in email. - Preserve a durable in-product route when provider link scanning or email forwarding could expose a bearer URL. - Explain retention and revocation truthfully; do not promise a file is deleted everywhere after an email was forwarded. ## Secure attachment handling Attachments are untrusted files whether uploaded through a web form or received through email. Allowlist business-required types, generate storage names, validate content rather than trusting MIME claims, limit bytes and count, isolate storage, scan or disarm under policy, and authorize every download. Avoid ZIP files as a casual workaround: compression can conceal active content or expand dramatically during inspection. ## Handle oversized-message failures ### Common oversize outcomes ```text HTTP 413 Application/provider rejected request body API 400/422 Attachment or total message violates provider contract SMTP 552 / 5.3.4 Message exceeds a fixed system or administrative limit Recipient gateway Policy rejects type, count, encrypted archive, or size Forwarding failure First mailbox accepted; later destination limit is lower Record the exact response and scope. Do not mark the address invalid merely because a particular message was too large. ``` For a transactional message, generate a lighter alternative with an authenticated download route when the business policy permits. Preserve one message intent and make fallback idempotent so the recipient does not receive both the giant attachment and repeated replacement messages after ambiguous provider outcomes. ## Email attachment production checklist - Document application, API request, provider message, SMTP, client, and recipient-route limits separately. - Measure raw upload bytes and serialized message bytes using explicit decimal or binary units. - Reserve headroom for base64, line wrapping, MIME, body alternatives, and provider transformations. - Keep large files out of queue payloads; reference controlled object storage. - Allowlist required types, generate filenames, scan under policy, and authorize access. - Use authenticated download pages for large or sensitive artifacts. - Test near-limit HTML-only, text-only, inline-image, multi-attachment, Unicode-name, and forwarded messages. - Store exact provider and recipient rejection evidence without suppressing an otherwise valid address. ## Frequently asked questions ## What is the maximum email attachment size? There is no universal maximum. Personal Gmail currently documents 25 MB of attachments, Outlook.com documents a 25 MB file limit, and business administrators and providers can configure different values. The effective limit is the smallest limit across every system on the route and may apply to the encoded message rather than raw files. ## Why is a 20 MB attachment larger in email? Binary files are commonly base64-encoded for MIME. The core encoding expands three input bytes to four output characters, then line breaks, MIME headers, boundaries, and the message body add more. A 20 MB raw file is roughly 27 MB after base64 and wrapping before other content. ## Should an application email large files as attachments? Usually not. A secure, authenticated application download is easier to revoke, audit, update, and keep within mailbox limits. Attach small artifacts when offline access or an external workflow truly requires it and the complete route supports the serialized size. ## Check HTML and total message weight before sending Inspect body bytes, image sources, clipping risk, transfer assumptions, and an explicit attachment budget before the provider or recipient rejects the message. [Open the email size checker](https://emailbump.com/tools/email-size-checker) ## Test the full message path - [Email sandbox](https://emailbump.com/blog/email-sandbox-testing) — Capture raw MIME, attachments, HTML, text, links, and failure cases safely. - [Inbound processing](https://emailbump.com/blog/inbound-email-processing) — Treat received attachments as hostile uploads with quarantine and authorization. - [REST email API](https://emailbump.com/blog/send-email-rest-api) — Handle provider request limits, timeouts, retries, and delivery evidence. - [HTML to plain text](https://emailbump.com/tools/html-to-plain-text-converter) — Produce a meaningful text alternative without duplicating hidden markup. ## Sources - [RFC 2045: MIME Part One](https://www.rfc-editor.org/rfc/rfc2045) - [Gmail attachment help](https://support.google.com/mail/answer/6584) - [Google Workspace: 2026 Enterprise Plus attachment limits](https://workspaceupdates.googleblog.com/2026/02/ending-larger-attachments-in-gmail-new-50MB-limit-for-Enterprise-Plus.html) - [Microsoft Outlook.com sending limits](https://support.microsoft.com/en-US/Outlook/sending-limits-in-outlook-com) - [Microsoft Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits) - [OWASP File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)