Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 64 of 221; 24 results per page.
A base64 text/plain message in iso-8859-1 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
The HTML body references a Content-ID that no part in the message provides: the everyday result of a forward that dropped an attachment. A renderer should show the alt text and carry on, not emit a broken external request or fail the whole message.
An HTML body referencing two base64 PNG parts by Content-ID, both resolved. This is the baseline for the three related/cid fixtures beside it: everything a cid resolver needs is present and correctly spelled.
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.
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.
A To: header listing 24 addresses, folded after every comma. Address-list parsers that unfold and split in the wrong order produce addresses with a leading space or lose the display name of every recipient after the first.
A single header whose value is one 1,001-character token with no whitespace, making the line 1,024 octets, past the 998-octet limit RFC 5322 sets and impossible to fold. Fixed-size line buffers truncate here, and the truncation is silent.
A Subject split mid-word across two adjacent encoded-words. RFC 2047 requires the linear whitespace between them to be discarded, so the correct result is one word; a decoder that keeps the space renders a split that reads as a typo.
An attachment with a bare Content-Disposition: attachment and no name in either header. A client has to invent a filename, and the extension it invents decides whether the saved file opens as a spreadsheet or as unknown binary.
RFC 822 message with a text/calendar REQUEST attachment, for calendar invite importers.
Cancel twin for the SAMPLE calendar invite: same UID, SEQUENCE bumped, METHOD=CANCEL.
A multipart/related message with an HTML body referencing a CID-inline PNG, for email client and MIME parser tests.
SPF passes and DKIM passes, yet DMARC fails, because the signing domain is the relay's, not the From domain's, and the policy demands strict alignment. Any dashboard that reports authentication by reading dkim= alone shows this message as trustworthy.
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.
