
EML — Nested Multipart
Nested MIME (mixed wrapping alternative plus a text attachment) — for deep MIME tree walkers.
- File
- EML · Mime
- Use case
- Email parsingConversion testing
Search files, editable visual templates, and live browser targets from one registry-backed directory. Filtered query views stay crawlable for links but are deliberately noindex; the stable taxonomy pages below remain the canonical search surfaces.
Page 3 of 5; 24 results per page.

Nested MIME (mixed wrapping alternative plus a text attachment) — for deep MIME tree walkers.

A quoted-printable text/plain message in utf-8 whose body carries accented French text, guillemets, an em dash and a euro sign. It is the exact twin of the base64 message beside it: both decode to the same 247 octets, so a decoder can be diffed against a known-equal pair.

A quoted-printable text/plain message in utf-8 whose body starts a line with "From " and holds a lone "." line, which quoted-printable escapes as =46rom and =2E. It is the exact twin of the base64 message beside it: both decode to the same 219 octets, so a decoder can be diffed against a known-equal pair.

A quoted-printable text/plain message in iso-8859-1 whose body is single-byte ISO-8859-1 rather than UTF-8, so each umlaut is one octet. It is the exact twin of the base64 message beside it: both decode to the same 176 octets, so a decoder can be diffed against a known-equal pair.

A quoted-printable text/plain message in utf-8 whose body holds a single line far past 76 columns, forcing quoted-printable soft breaks. It is the exact twin of the base64 message beside it: both decode to the same 451 octets, so a decoder can be diffed against a known-equal pair.

A quoted-printable text/plain message in utf-8 whose body ends lines with spaces and tabs that quoted-printable must encode as =20 and =09. It is the exact twin of the base64 message beside it: both decode to the same 193 octets, so a decoder can be diffed against a known-equal pair.

A References header that lists the same two Message-IDs twice, in a repeating order — what a client produces when it appends without checking. A threader that treats the chain as a literal path builds a cycle or reports a depth of four for a two-deep thread.

An eight-deep References chain folded so each Message-ID sits on its own line. There is no comma between msg-ids in this header, so a parser that splits on the line break rather than unfolding first ends up with ids that carry a leading space.

The immediate parent named by In-Reply-To was never delivered, but its grandparent is in the References chain. A threader has to fall back up the chain instead of orphaning the message — the everyday case after a deleted or filtered message.

A reply that declares its parent only through In-Reply-To. Threading code that builds ancestry from References alone files this message as a new thread root, splitting a conversation in the message list.

The same reply expressed the other way round: a References chain with no In-Reply-To. Together with its twin it isolates which of the two headers a threading implementation actually reads, since either alone is sufficient under RFC 5322.

A single Subject built from three encoded-words in three charsets and two encodings. RFC 2047 allows this, and it is what happens when a subject is quoted through several mail systems, so each word has to be decoded on its own terms.

The ISO-8859-1 Subject again, base64-encoded instead of Q-encoded. Base64 hides the charset entirely, so this is the fixture that catches a decoder guessing the charset from the octets instead of reading the encoded-word's charset token.

A German Subject encoded as ISO-8859-1 'Q', the shape most legacy mail actually uses. Each umlaut is one =XX escape, so a decoder that assumes UTF-8 produces mojibake rather than a clean error.

A Russian Subject as a KOI8-R base64 encoded-word. KOI8-R orders Cyrillic letters by Latin transliteration rather than alphabetically, so a decoder that substitutes any other Cyrillic codepage returns readable-looking but wrong text.

A Japanese Subject as a Shift_JIS base64 encoded-word. Shift_JIS second bytes overlap ASCII punctuation values, so a decoder that scans the decoded octets for delimiters before converting the charset splits the string in the wrong place.

A Subject header carrying accented Latin text and an emoji as a single UTF-8 base64 encoded-word. Its Q-encoded twin decodes to the identical string, so the two together isolate the encoding from the charset.

The same Subject as the UTF-8 'B' twin, written with 'Q' encoding instead: underscores stand for spaces and every non-token octet is an =XX escape. A decoder that forgets the underscore rule produces visibly different text from its twin.

The conformant answer to non-ASCII filenames: a filename split into three numbered RFC 2231 segments with a charset and a language tag, plus size and creation-date parameters. Parsers commonly handle filename*= but not the numbered continuation form.

S/MIME-shaped SAMPLE with a placeholder PKCS7 part (not a real signature) for MIME structure tests.

Two text/plain parts inside a mixed container, the second marked inline but carrying a filename. Clients split on this: some concatenate it into the body, some list it as an attachment because a filename is present, and the two behaviours look like different messages.

Threaded SAMPLE reply at depth 1 with a long References chain and bulky X-headers.

Threaded SAMPLE reply at depth 2 with a long References chain and bulky X-headers.

Threaded SAMPLE reply at depth 3 with a long References chain and bulky X-headers.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.