If you are searching for , , or , the practical question is not only "what number does the provider allow?"

The real question is how large a message becomes after encoding, whether the recipient system will accept it, and whether the message still behaves well in real inboxes.

Quick answer

  • Email size limits apply to the entire message, not only the attached file.
  • Attachments usually grow during MIME and base64 encoding.
  • A file that looks safe locally can exceed the provider limit once encoded.
  • At the time of writing, Google Workspace documents up to for sending and up to for receiving.
  • In practice, you should stay comfortably below hard provider caps and test real inbox behavior before launch.

What counts toward email size

Email size includes more than the attachment itself.

The total message size can include:

  • text and HTML bodies
  • inline images
  • file attachments
  • MIME boundaries and metadata
  • headers and tracking markup
  • signatures and formatting

That is why "my PDF is only 19 MB" does not necessarily mean the final message will stay under a 20 MB or 25 MB send limit.

Why attachments get bigger in transit

Attachments are often base64 encoded for transport. That can increase message size materially before the receiving system evaluates the message.

So the safe rule is:

  • do not aim directly at the provider's hard cap
  • leave margin for encoding overhead and template weight

If a file is already close to the provider limit, use a download link or hosted asset instead of attaching it directly.

Gmail size limits in practice

Google Workspace currently documents:

  • up to for sending
  • up to for receiving

That does not mean every file is a good idea to attach. A large message can still create:

  • delivery rejection after encoding
  • slow client rendering
  • mobile usability problems
  • clipping or truncation in some clients

Always verify the provider's current documentation before relying on a hard number in production.

Why large emails fail even before the hard cap

A message can perform badly before it is technically rejected.

Common issues:

  • attachment bounces near the limit
  • HTML messages load slowly on mobile
  • recipients struggle to preview or download files
  • spam filters treat unusual message structure as higher risk
  • large transactional messages increase retry and queue pressure

So email size is both a transport constraint and a user-experience constraint.

Practical size rules by workflow

Transactional emails

Keep the message body lean. If the email contains attachments, use them only when they are essential to the workflow.

Marketing emails

Use hosted images and lean HTML. A visually heavy template can create rendering and clipping issues even without large attachments.

File-heavy workflows

If the recipient needs a large file:

  1. upload it to a controlled download location
  2. send a secure link instead of the attachment
  3. test the full recipient experience

This is usually better than sending the attachment directly at the edge of the provider limit.

How to reduce email size

The practical options are:

  • compress or optimize attachments before send
  • host large files externally
  • reduce heavy inline assets
  • simplify bloated HTML templates
  • remove unnecessary duplicated markup or signature blocks

If a workflow depends on large attachments, treat size handling as a product decision, not a last-minute template tweak.

How to test large-email workflows

Do not stop at checking the local file size.

Test:

  1. whether the provider accepts the send
  2. whether the message arrives intact
  3. whether the recipient can open the attachment or link
  4. whether the email still renders correctly across clients

Useful related pages:

Use MailSlurp to validate attachment-heavy workflows

MailSlurp lets teams test what actually happens to large messages, not just estimate the size.

Use it to:

That turns attachment-size questions into a repeatable QA workflow.

FAQ

What is the email size limit?

There is no single universal email size limit. Each provider sets its own cap, and the total message size includes encoding overhead.

What is Gmail's attachment size limit?

Google Workspace currently documents up to for sending and up to for receiving.

Why does an attachment fail even when the file looks smaller than the limit?

Because MIME and base64 encoding can increase the final message size before the provider evaluates it.

Should I attach a file close to the provider limit?

Usually no. Leave margin or send a hosted download link instead.

Final take

Email size limits are transport limits plus workflow limits. Stay below the hard cap, account for encoding overhead, and test the real inbox experience before shipping attachment-heavy email.