Email attachment size and format limits

When to read this

You're setting up email forwarding for the first time and want to know what survives the pipeline, or you're investigating why a specific forwarded email didn't produce a document, or your vendor sends invoices in an unusual format (inline images, embedded HTML, archives) and you want to confirm it'll work.

For the general format reference (covering web upload, mobile, and email), see supported file types and sizes. This article is the email-specific version with a few attachment quirks particular to forwarding.

What's allowed in an attachment

When you forward an email to your u-…@in.taxiteasy.org address, every attachment is checked the same way as a direct upload to the web app:

• Format: PDF, JPG/JPEG, PNG, HEIC. Anything else is silently dropped at intake (the email is still processed but the unsupported attachment doesn't produce a document).
• Size: maximum 20 MB per attachment.
• Magic-byte check: the file's actual bytes must match the declared content type. A renamed .txt → .pdf won't slip through.

These rules are identical to the web-upload limits documented in supported file types and sizes. The 20 MB cap, the four-format allow-list, and the content-sniffing check apply everywhere — there's no email-specific exception.

What about the email itself

A few aspects of the email around the attachment are processed differently:

• Body text (plain text or HTML) — processed once for classification, then discarded. Never permanently stored. Even if you forward a deeply confidential email, the body itself is not retained on our side.
• Headers (sender, date, subject) — stored in the Activity log for audit and duplicate detection. No other headers are kept.
• Inline images (images embedded in the email body, not as proper attachments) — ignored. We only process real attachments. If an "invoice" is rendered as an inline image inside the email body (some vendors do this with HTML emails), it won't be extracted; save it locally and upload directly.

Multi-attachment emails

One email can carry multiple attachments. Each goes through the pipeline independently:

• 3 invoices in one email = 3 documents created = 3 against your monthly quota.
• 1 PDF + 1 unsupported .docx = 1 document (the PDF), the .docx is silently dropped.
• 0 attachments + invoice-shaped body = 0 documents (we don't OCR email bodies into documents; if the receipt is in the body, save and upload manually).

Duplicate-detection still works per-attachment. If you forward the same invoice attached to two different emails (e.g. one forwarded, one originally received), the second-arriving attachment is recognised by file hash and skipped — no second document, no quota use.

Unsupported attachment types and how to handle them

• .eml / .msg (inner email files, e.g. when you "send as attachment" in Outlook) — not extracted. Forward the original email directly, not as an attachment. If you must send an .eml (forensic / archival), upload to the web instead; .eml processing is on the 2026 roadmap.
• Archives (.zip, .rar, .7z, .tar) — not unpacked. Extract locally, then re-forward as direct attachments (or upload to the web). We deliberately don't auto-unpack archives server-side; that's a footgun for malware delivery.
• Office formats (.docx, .xlsx, .pptx, .odt) — convert to PDF first. Most office suites have a one-click PDF export. Forward the PDF.
• Encrypted PDFs — decrypt and re-save without the password, then forward. We can't process encrypted PDFs (and wouldn't want to store decrypted versions of password-protected documents on your behalf).
• TIFF, BMP, GIF, WebP, SVG — convert to JPG or PNG first. Most image editors do this in seconds.

When an unsupported attachment is dropped, the Activity log entry includes attachments_dropped: [list of filenames] so you can see what was skipped and why.

Multi-forwarding (forward an already-forwarded email)

Multi-hop forwarding works but with caveats:

• The classifier sees the last sender on the chain. If your forwarding-bookkeeper-mailbox forwards everything to TaxItEasy, the From: in our Activity log is the bookkeeper-mailbox, not the original vendor. The duplicate-detector still works on attachment hashes, so re-forwarded copies don't create duplicate documents.
• SPF often fails after one hop but DKIM usually survives. Our authentication check (the inbound address explained) accepts either-passes, so multi-hop forwarding generally works.
• Some forwarders strip attachments to reduce email size (rare, mostly Yahoo Mail in the past). If you forward and the attachment doesn't appear in the Activity log, check whether the forwarding service is stripping it.

For one-step forwarding from your real inbox directly to TaxItEasy, none of these issues apply.

Edge cases

My attachment is 25 MB and got rejected. Compress or split before forwarding. Most PDF viewers can re-save at lower resolution to drop file size (Preview on macOS: File → Export → Quartz Filter → Reduce File Size; Adobe Acrobat: File → Save As Other → Reduced Size PDF). For long PDFs, split into multiple files and forward each individually.

I forwarded an Outlook email with a .msg attached (you wrapped your original email as a forwarded attachment instead of inline forwarding). The .msg isn't a supported format, so the inner email is ignored. Forward the original email directly, not as an attachment — most email clients have "Forward inline" as the default behaviour; "Forward as attachment" is the alternative that produces .msg / .eml attachments.

The vendor sent me a .zip with the invoice inside. Archives aren't unpacked at intake. Extract the PDF locally, then upload or forward it directly. Forwarding the .zip itself produces an attachments_dropped log entry and no document.

I forwarded a long email thread with embedded inline images. Inline images aren't extracted — we don't OCR conversation screenshots into documents. If an inline image is actually the invoice (some receipt formats do this), save the image locally on your device first, then upload directly to the web app.

Got a notice that "no attachments were extracted" but I'm sure there was one. Check the email in your sent folder — sometimes "real attachments" are actually inline images in disguise, especially on iOS Mail. The simplest check: open the forwarded email, look at the attachment block at the bottom. If the file appears as a clickable filename with a paperclip icon, it's a real attachment; if it appears inside the body alongside text, it's inline and won't be extracted. Save the file locally, then forward or upload it as a true attachment.

I forwarded a multi-page scanned PDF (50 pages, 18 MB) and only got one document. That's correct. Multi-page PDFs are treated as one document, not one per page. The extraction reads all pages and produces a single document record. See supported file types and sizes for the multi-page semantics.

Two attachments of the same invoice in one email. Duplicate detection runs per-attachment-hash. If the two attachments have identical bytes (same file attached twice), only one document is created and quota is consumed once. If they differ even slightly (e.g. two PDF re-exports with different metadata), both create documents.

My attachment passed the size check but extraction failed. Different article — see upload failed — troubleshooting and the OCR extracted the wrong fields for post-intake extraction problems.

Why no .docx support — my vendor sends Word invoices. Word lacks a consistent text/layout structure for invoice extraction. Different invoice templates render completely differently when parsed as Word XML. PDF locks the rendering, which is why it's the invoice standard. Converting Word to PDF (built into Word / LibreOffice) takes 5 seconds.

Related

• Supported file types and sizes — same rules in one canonical reference
• Set up email forwarding — getting forwarding configured
• What happens when you forward a newsletter — the classification step before extraction
• Upload failed — troubleshooting — when extraction itself fails