What makes Base64 MIME-specific?

RFC 2045 (MIME) uses the standard Base64 alphabet but adds a line-length rule: the encoded text is split into lines of at most 76 characters, each terminated by a CRLF. This keeps it within the line limits of email and other text transports.

Are the line breaks CRLF or LF?

RFC 2045 specifies CRLF (carriage return + line feed, \r\n) between lines. This tool emits CRLF, which is what email and MIME parsers expect.

Will it decode Base64 that has no line breaks?

Yes. When decoding, all whitespace and line breaks are stripped first, so it accepts both wrapped MIME Base64 and a single unbroken line of Base64.

How is the padding handled?

The standard = padding is appended so the encoded length before wrapping is always a multiple of four. On decode, the padding is validated and removed before the bytes are reconstructed.

What is the Base64 MIME Encoder (Line-Wrapped)?

Free MIME Base64 encoder and decoder following RFC 2045 — uses the standard alphabet with = padding and wraps output at 76 characters using CRLF line breaks, exactly as email transfer encoding requires. Runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Base64 MIME Encoder (Line-Wrapped)

Name: Base64 MIME Encoder (Line-Wrapped)
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

MIME Base64 is the form of Base64 defined in RFC 2045 for the Content-Transfer-Encoding: base64 used by email and many internet message formats. It is ordinary Base64 — the standard A–Z a–z 0–9 + / alphabet with = padding — with one extra rule: the output is broken into lines of no more than 76 characters, separated by CRLF. This tool produces correctly wrapped MIME Base64 and decodes it back.

How it works

To encode, the text is converted to UTF-8 bytes and processed three bytes at a time. Each 3-byte (24-bit) group becomes four 6-bit symbols from the alphabet. When the final group has only one or two bytes, the missing positions are filled with = so the symbol count stays a multiple of four. Finally the continuous Base64 string is sliced into 76-character lines joined by \r\n, as MIME requires.

To decode, all whitespace and line breaks are removed, the remaining characters are validated against the alphabet, and the length is checked to be a multiple of four. The 6-bit values are repacked into bytes and read back as UTF-8, with a clear error for invalid characters, bad length, or non-UTF-8 bytes.

Why 76 characters per line?

The 76-character limit is not arbitrary. Early SMTP mail systems imposed a maximum line length of around 78 characters per line (the “998 character hard limit” is modern; old MTAs enforced stricter limits). By wrapping at 76 characters, MIME-encoded content plus the trailing CRLF sequence stays safely within that range for the entire history of the standard. RFC 2045 specifies that decoders must ignore characters that are not in the Base64 alphabet — specifically including those CRLF line breaks — so encoders can wrap freely and decoders will strip the whitespace automatically.

Where MIME Base64 appears

Email attachments: when you attach a PDF to an email, the email client encodes the file in MIME Base64 under a Content-Transfer-Encoding: base64 header. The body of that MIME part is exactly what this tool produces.
Inline images in email HTML: <img src="data:image/png;base64,..."> embedded in HTML email often uses MIME-style line wrapping to keep individual lines short, even though HTML data URIs do not technically require it.
S/MIME and PGP message armoring: encrypted and signed email bodies use MIME Base64 for the binary ciphertext or signature block.
LDAP attributes: some directory systems transmit binary attribute values (photos, certificates) as MIME Base64 in LDIF format.

Example

Encoding Gera Tools produces R2VyYSBUb29scw==. Because it is shorter than 76 characters, it stays on a single line. A longer input — such as a paragraph — would be split into several 76-character lines with CRLF between them, which you can see in the raw source of any email attachment.

The only difference between this and a plain Base64 encoder is the 76-character line wrapping and the CRLF line terminators; the underlying bytes are identical. Everything runs locally in your browser, so nothing you type is uploaded.