Understanding MIME

Before the early 1990s, email systems were extremely limited. An email could only contain plain 7-bit ASCII text, meaning:

• no images
• no binary files
• no PDFs
• no accented characters or non-English languages

Trying to paste a binary file into an email would simply corrupt it. Different systems (IBM, DEC, Unix) also used different encodings, which made things even worse.

MIME (Multipurpose Internet Mail Extensions) was created to solve this problem.

Why MIME Was Introduced

Email needed a way to transport any kind of data, while still remaining compatible with old 7-bit mail servers. So MIME introduced three key ideas:

1. A standard label describing the type of content
   This is the origin of Content-Type: image/png, text/plain, etc.
2. A safe encoding for binary data
   Binary files are converted into text-safe formats like base64.
3. A way to combine multiple parts
   A single email could now contain both text and attachments.

This allowed email clients to understand what they were receiving, how to decode it, and how to present it.

How MIME Appears Inside an Email

Here is a simplified example of how an attached PNG image looks inside a raw email:

 1MIME-Version: 1.0
 2Content-Type: multipart/mixed; boundary=abc123
 3
 4--abc123
 5Content-Type: text/plain; charset=UTF-8
 6
 7Hello, here is the image.
 8
 9--abc123
10Content-Type: image/png
11Content-Transfer-Encoding: base64
12
13iVBORw0KGgoAAAANSUhEUgAAAAUA...
14--abc123--

Why HTTP Adopted MIME

When the Web started to grow, HTTP also needed a way to describe what kind of content it was sending. A server might return:

• an HTML page
• a JSON API response
• an image
• a video
• a PDF
• a stylesheet or JavaScript file

Instead of inventing a new system, HTTP simply reused MIME's content-type idea.
This is why HTTP responses include headers like:

1Content-Type: text/html
2Content-Type: application/json
3Content-Type: image/jpeg
4Content-Type: video/mp4