Gera Tools

B-Encoding (RFC 2047) Encoder

MIME header word encoding: =?UTF-8?B?...?= Base64 variant

Encode non-ASCII email header words such as subjects and names using RFC 2047 B-encoding, the Base64 variant producing =?UTF-8?B?...?=. Also decodes B encoded-words back to text. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is RFC 2047 B-encoding?

B-encoding is the Base64 variant of the RFC 2047 encoded-word syntax. The header value is converted to bytes in the named charset, Base64-encoded, and wrapped as =?charset?B?base64?=. The capital B marks Base64, distinguishing it from the Q quoted-printable variant.

RFC 2047 B-encoding lets you put non-ASCII text into email headers using a Base64-wrapped encoded-word: =?UTF-8?B?...?=. It is the compact counterpart to Q-encoding and is preferred when most of the text is non-ASCII. This tool encodes and decodes B encoded-words in your browser.

Why email headers need encoding at all

The original SMTP protocol and MIME standard were designed around a 7-bit ASCII constraint. Email headers — the Subject:, From:, and To: fields — are transmitted as plain ASCII text, which means any character outside that set needs to be encoded before it goes into a header line.

RFC 2047 defined the encoded-word as the solution: a self-contained unit that declares the character set, the encoding method, and the encoded text, all in a form that is entirely ASCII-safe. A mail relay or server that doesn’t understand the encoding passes it through unchanged; a mail client that does understand it decodes and displays the original text.

How it works

The encoded-word format is =?charset?encoding?encoded-text?=. For the B encoding:

  1. The text is converted to UTF-8 bytes with TextEncoder.
  2. Those bytes are Base64-encoded using the standard alphabet A-Z a-z 0-9 + / with = padding.
  3. The result is wrapped as =?UTF-8?B?...?=.

Decoding reverses the process: the tool parses the charset and the B marker, Base64-decodes the body back to bytes, and runs a strict UTF-8 decode.

B-encoding vs Q-encoding: when to use which

Both B-encoding and Q-encoding (the quoted-printable variant, marked with a Q in the encoded-word) produce RFC 2047 compliant output. The choice is purely about compactness:

  • B-encoding is more compact when most characters are non-ASCII, because Base64 encodes every byte at a fixed cost (4 ASCII characters per 3 bytes). For a Japanese or Arabic subject where nearly every character requires multi-byte UTF-8 encoding, B-encoding wins.
  • Q-encoding preserves the readability of mostly-ASCII text, encoding only the characters that need it with =XX escape sequences. For a French subject like Réponse immédiate with only two accented characters, Q-encoding produces a more human-readable header.

In practice, many email clients and libraries default to B-encoding for non-ASCII subjects regardless, because it is simpler to implement correctly.

Worked example

The subject 日本語 (Japanese for “Japanese language”) in UTF-8 is three characters, each encoded as three bytes, totalling nine bytes. Base64 of nine bytes produces 12 Base64 characters (9 × 4/3 = 12). The full encoded-word is:

=?UTF-8?B?5pel5pys6Kqe?=

That is 24 characters total — well within the 75-character limit per encoded-word that RFC 2047 mandates.

For a longer subject like a full sentence in Arabic or Chinese, the tool will flag when the output exceeds 75 characters, since a real mail client expects the header to be split into multiple encoded-words separated by linear whitespace (spaces or tabs), and each encoded-word is decoded independently on reassembly.

Decoding suspicious email headers

If you receive an email with a Subject: field that looks like =?UTF-8?B?SGVsbG8gV29ybGQ=?=, paste it into this tool in decode mode to read the original text. This is also useful for debugging email pipelines where headers arrive garbled or where the encoding declaration (B vs Q) differs from what your parser expects.