Base64 attachments in mobile email clients

Mobile email clients decode Content-Transfer-Encoding: base64 attachments when the MIME part is well-formed; they fail closed—or show garbage—when padding, charset, or declared types are wrong. Build a minimal fixture, observe declared type vs rendered behavior, and never auto-execute decoded payloads. Safe HTML preview tools help reading mail; they are not a sandbox for arbitrary binary trust.

Scoped under email message format. Mailby Quick Inbox previews HTML safely relative to script execution in-page; treat attachments as untrusted until scanned in your own workflow.

Mobile client context and boundaries

Mobile MUAs (iOS Mail, Gmail app, Outlook mobile) differ in:

• Inline vs download-only for large base64 parts
• Handling of application/octet-stream vs concrete types
• Truncation of huge encoded bodies

Boundaries:

• Technical explainer for received mail—not how to weaponize attachments.
• Standards: RFC 2045 (MIME), base64 transfer encoding sections.
• Temporary inboxes do not make attachments safer—only shorter-lived.

Related privacy: tracking pixels for HTML image fetches distinct from attachments.

Fixture: working and broken parts

Working path (editorial fixture, 2026-09-24):

Multipart message with a text/plain part plus:

Content-Type: application/pdf; name="receipt.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="receipt.pdf"

JVBERi0xLjQKJeLjz9MKMyAwIG9iago8PC9UeXBlIC9QYWdl... (valid padding)

Mobile client showed a PDF chip; tap opened viewer.

Failure path:

Same headers but base64 string stripped of = padding and with an inserted space mid-line without proper MIME folding. Client showed “can’t open attachment” or zero-byte file. Symptom looks like “mobile email is broken”; root cause is invalid encoding.

Limitation: we do not ship malware samples; use harmless PDF/txt fixtures only.

Mechanism

Base64 maps binary to ASCII-safe lines for SMTP. Decoders expect alphabet [A-Za-z0-9+/] and padding. Declared Content-Type guides which viewer opens; mismatch (PDF bytes labeled image/png) yields failed preview.

Security implication: users trust icons. A .pdf filename with Content-Type: application/pdf can still be non-PDF bytes. Mobile OS viewers add a layer; do not rely on filename alone.

Rendering table

Raw part	Declared type	Observed rendering	Accessibility/security implication
Valid PDF base64	application/pdf	Chip → system viewer	Confirm size; scan if untrusted
Valid PNG base64	image/png	Inline or gallery	Remote? No—embedded; still untrusted source
Valid bytes	application/octet-stream	Download only	Better default for unknown
Broken padding	application/pdf	Error / empty	Do not re-download loops from phishing
Huge base64	any	Truncation / lag	Battery/network cost on mobile
HTML + attachment	multipart/mixed	Body + chip	Scripts in HTML blocked by good clients

Worked example for developers

When sending from Laravel/Node:

1. Use the mailer’s attachment API—do not hand-roll base64 unless you must.
2. Set accurate MIME types.
3. Test on one iOS and one Android client.
4. Negative test: corrupt padding in staging; assert client error, not silent wrong file.
5. Optional: receive a copy in Quick Inbox to inspect headers if your preview exposes them; otherwise use Mailpit raw source.

Pair with Laravel verification email testing for the generation path.

When durable mailboxes matter

Legal attachments (contracts, invoices) need durable storage and backup—temporary inbox retention is intentionally short (data retention). Use disposable receive only for throwaway QA samples.

Short answers

What causes base64 attachment issues on mobile?
Invalid encoding, type mismatch, size limits, or client policy—not always “mobile is broken.”

What should I do first?
View raw MIME; validate base64; confirm Content-Type; retry on a second client.

When is a permanent address safer?
For attachments you must keep or that contain personal data.

What evidence changes the recommendation?
If desktop opens and mobile fails on the same bytes, suspect mobile size/type policy.

Sources, test date, limitations

• Fixtures exercised editorially 2026-09-24.
• RFC 2045.
• Product preview limits: security, inbox.
• Limitation: client versions change; retest after OS upgrades.

Line length, folding, and “almost valid” base64

MIME expects base64 lines soft-wrapped near 76 characters. Some naive encoders emit one giant line. Many mobile clients still decode it; some gateways inject spaces or CRLF that corrupt the alphabet. If desktop Thunderbird opens a file and iOS Mail does not, dump the raw part and validate length modulo 4, alphabet, and padding.

Automated check in CI: generate attachment via your mailer, parse with a MIME library, decode round-trip, hash-compare to the original bytes. Do this before buying device labs time.

Inline CID images versus attachments

Content-Disposition: inline with Content-ID behaves differently from attachment. Mobile clients may auto-display inline images (privacy adjacent to pixels) while requiring taps for attachments. Test both if your template embeds logos as base64 CID parts—those fetches are local to the message, not remote pixels, but they still affect size and battery.

How this differs from the email-message-format hub

The hub surveys formats. This article is a base64-on-mobile teardown with working/broken fixtures and a rendering table. It pairs with Laravel generation tests when you own the sending app.

Accessibility notes

Filename pronunciations, huge PDFs, and missing text alternatives on inline images hurt VoiceOver/TalkBack users. Prefer real attachments with clear names over tiny unlabeled inline blobs. If the message body explains the attachment in text/plain, more clients remain usable when HTML fails.

Security handling workflow

1. Do not open unexpected attachments on the phone you use for banking MFA.
2. Prefer open-in-sandbox viewers.
3. For developer samples, use dedicated QA devices.
4. Temporary inboxes reduce long-term storage of hostile payloads if you delete promptly—see message body lifecycle—but first open still occurs on-device.

Size budgets

Keep encoded attachments small for mobile verification mail (receipts, not 20MB videos). ESP and client limits differ. Measure base64 expansion (~4/3) when budgeting.

Negative test catalog

Mutation	Expect
Remove padding	Fail open
Truncate 10 bytes	Fail or corrupt
Wrong Content-Type	Wrong viewer / fail
Empty body	Fail
Correct bytes	Round-trip hash match

Wire these into staging sends monthly; mobile OS upgrades break assumptions quietly.

Charset and filename parameters

filename* with RFC 5987 encoding matters for non-ASCII names on mobile. Mis-encoded filenames show mojibake or block saves. Test with a Japanese or Spanish filename in staging if your users need it.

Encrypted archives

Password-zip attachments frustrate mobile users and lure phishing (“password is 1234”). Prefer direct PDF over encrypted zip for legitimate receipts. If you must encrypt, send the password out of band—not in the same email body.

Client update regressions

Pin a quarterly device matrix: current iOS Mail, current Gmail Android, one OEM skin. Re-run the negative base64 catalog after major OS upgrades. Document pass/fail in the engineering wiki beside the Laravel mail suite.

Building the broken fixture on purpose

Create tests/fixtures/mail/broken-padding.eml with a single corrupted attachment. Feed it to Mailpit; open on device lab. Record screenshots of error states for support playbooks. Engineers learning MIME faster from one broken file than from ten green paths.

Streaming and memory pressure

Some mobile clients decode entire base64 parts into memory. A 15MB PDF becomes ~20MB encoded and can crash low-end devices. Cap attachment sizes in sending code; for larger files, send HTTPS download links with expiry instead of inline base64.

Content-Disposition filename vs name parameter

Mismatch between name= on Content-Type and filename= on Content-Disposition confuses clients. Standardize via your mail library’s attachment helper—avoid hand-written headers unless you have tests.

Pairing with temporary preview

Receiving a QA copy in Quick Inbox helps inspect HTML; attachment handling may differ from native mobile MUAs. Always confirm on-device for mobile claims. Document that limitation in your test plan so PMs do not treat web preview as iOS proof.

Multipart related pitfalls

When HTML references cid: images that are themselves base64 parts, missing Content-ID headers show broken image icons that users mistake for “attachment failure.” Validate CIDs in generation tests. Keep verification OTPs in text/plain so mobile users still succeed when HTML related parts break.

Legal holds vs temp preview

Do not use temporary inboxes to store attachments under legal hold. Preview, then move to compliant storage. Short TTL conflicts with preservation duties—choose the duty first.

Uuencode and legacy transfer encodings

Legacy systems still emit uuencode. Mobile clients vary wildly. Prefer converting outbound mail to base64 or 7bit/quoted-printable via modern libraries. If you must accept inbound uuencode for migration, decode server-side before mobile users ever see it.

Appendix: round-trip hash test idea

original = sha256(file)
send mail with attachment via app
receive in Mailpit
decode base64 part
assert sha256(decoded) == original

Run in CI against Mailpit. Promote to device lab only when round-trip fails on specific clients—then you know it is a client bug, not your encoder.

Reader takeaway for non-developers

If a mobile attachment will not open, ask the sender for a cloud link or a resent message before assuming your phone is broken. If you are the sender, use your mail library’s attachment API and test one iOS and one Android device. Temporary inboxes help QA previews; they are not a substitute for on-device checks when mobile rendering is the claim you make in release notes.

Heuristics for support tickets

When users report “attachment blank on phone,” collect: client name/version, approximate size, whether desktop works, and a sanitized sample. Reproduce with the negative catalog before changing production encoders. Many tickets close as “user had no storage” or “MDM blocked downloads”—not MIME bugs. Still, keep the round-trip hash test green so you can say “encoder OK” with evidence.

Reader checklist

• Prefer library attachment helpers
• Round-trip hash in CI via Mailpit
• Corrupt-padding negative case
• Test iOS and Android yearly after OS upgrades
• Keep verification OTPs in text/plain
• Use durable storage for keepers; temp only for QA previews

Bottom line for senders

Correct MIME beats clever custom encoders. If mobile users cannot open the file, fix headers and size first—then retest on devices, not only in web preview.

Conclusion

Base64 on mobile is boring when MIME is correct and scary when it is not. Ship accurate types, test broken padding as a negative case, and keep sensitive attachments off disposable clocks. Use Quick Inbox only when its preview supports the check you need—and treat every attachment as untrusted input.