MHTML test messages

I have prepared a set of test messages which demonstrate different variations of sending e-mail in HTML format according to RFC 2110.

Warning: Since the test cases were developed, the MHTML group has decided to abolish the Content-Base headers. This means that some of the test cases are at present not up-to-date. They will be modified to agree with the latest version of the MHTML standard. A revised set of these test messages can be found at

The URL-s for retrieval of these test message files is<file name> where <file name> is the file name in the table below.

The URL contains a tar file with all the test messages combined in one file.

For more information about sending HTML in aggregate multipart MIME messages, see URL

Last revision: 27 October 1997. Last changes: Corrected a bug in test-17.mime, all files now have CRLF as line break character.

By Jacob Palme at the Department of Computer and Systems Sciences, Stockholm University and KTH.

File name



Three body parts, one HTML, two inline GIFs, the inline GIFs have Content-Disposition. Uses CID URLs to the inline GIFs.


Same as test-1.mime, but no Content-Disposition headers.


Same as test-2.mime, but the HTML part has no <HEAD>.


Same as test-3.mime, but a BACKGROUND has been added to the body, the background is enclosed as an additional GIF-formatted body part.


Same as test-4.mime, but only one body part, all images have to be retrieved using HTTP.


Same as test-4.mime, but one of the images is not included and has to be retrieved using HTTP.


Same as test-4, but uses relative Content-Location instead of CID to reference the image body parts.


Same as test-4, but includes Content-Base referring to non-existing directory.


Same as test-8, but includes Content-Base which has to be resolved.


Same as test-8, but Content-Base must be recursively resolved from outermost heading, also one image is missing and has to be retrieved using HTTP.


Same as test-8, but the same relative URL but different base is used for different parts.


Same as test-8, but uses multipart/alternative inside multipart/related to provide a choice between a plain text and HTML rendition.


Same as test-8, but uses multipart/alternative outside multipart/related to provide a choice between plain text and multipart/related.


A multipart/mixed, which contains two body parts, each of type multipart/related, and each of them a simplified variant of test-8. The same relative URL is used to designate two different objects with the same relative and absolute URL but different content in the two multipart/related sets. (Based on a suggestion by Larry Masinter.)


Similar to test-14 but uses CID-s for references inside the message. I made this example to test how different backgrounds in two HTML body parts are handled. Body parts have both Content-Location and Content-ID at the same time.


The main HTML object of this test message is a FRAMESET with three FRAMEs includes as separate HTML objects. One of the FRAMEs uses three GIF images. All hyperlinks are of the CID kind.


Similar to test-16, but hyperlinks are of the HTTP kind with Content-Location to identify the linked objects.


Similar to test-15, but one of the hyperlinks is of the CID type and the other of the relative URL type. (I cannot believe anyone would ever want to generate something like this.)

Good software should be able to handle incorrect input in some fashion, at least not crash on receiving it. Especially in the case of web browsers, it is customarily agreed that these should try to render incorrect HTML documents as well as possible. The following test messages contain either intentional deviances from MHTML in order to test the capability of handling deviant messages. Most of them are not really errors, they just use facilities not covered by the MHTML standard.


Same as test-1.mime, but one hyperlinked body part is not included, and another not-linked body part is included instead.


Same as test-1.mime, but uses Content-Type: multipart/mixed instead of Content-Type: multipart/related. (Not really an error, but not part of the MHTML standard.)


Same as test-1.mime, but one of the linked body parts has Content-Disposition: attachment instead of Content-Disposition: inline. (MHTML says that Content-Disposition should be ignored within multipart/related, so this should not have any effect on rendering.) (Not really an error, since MHTML says that Content-Disposition should be ignored.)


Similar to test-1.mime, but one of the hyperlinked body parts is outside of the multipart/related. (Not really an error, but not part of the MHTML standard.)


Similar to test-1.mime, but one of the hyperlinked body parts is part of another message, not of this message. (Not really an error, but not part of the MHTML standard.)

I have tested the test-examples (not the error-examples) with Eudora Pro 3.1.1 and Netscape Communicator 4.03 on a Macintosh and Pine 3.95 on a Unix computer. All of these are early first implementations of MHTML, so it is not surprising that none of them could handle all the test examples correctly. Of particular interest is:

Back to MHTML main page