Turn =?UTF-8?B?… mail subjects back into readable text, and generate them
Mail headers were originally limited to ASCII, so a non-ASCII subject travels as something like =?UTF-8?B?44OG44K544OI?=. RFC 2047 calls this an encoded-word. Between =? and ?= there are three parts: the charset, the transfer encoding, and the payload. The transfer encoding is either B (Base64) or Q (a Quoted-Printable variant).
A single encoded-word is limited to 75 characters, so long subjects are split into several. RFC 2047 says that when encoded-words are separated only by whitespace, that whitespace must be dropped when displaying. Skip this and the subject gains stray spaces at every split point. This tool removes it, while keeping whitespace between an encoded-word and ordinary text.
_ becomes a space in Q encodingQ encoding is almost the same as Quoted-Printable, with one difference for header use: a single _ stands for a space (0x20). That is why =?UTF-8?Q?Hello_World?= decodes to "Hello World".
The browser built-in TextEncoder emits UTF-8 and nothing else. Producing ISO-2022-JP or Shift_JIS would require a separate conversion table, and this site does not add external libraries for it, so the encode side is limited to UTF-8. Decoding still covers ISO-2022-JP, Shift_JIS and EUC-JP because TextDecoder supports them.
Yes. Decoding covers ISO-2022-JP, Shift_JIS, EUC-JP and UTF-8. If a charset your browser does not support is named, the bytes are read as UTF-8 and the breakdown says so.
No. Parsing, conversion and download all happen inside your browser. Nothing you enter is sent to a server.
Yes. You can paste a full line such as one starting with Subject:. Only the encoded-word parts are converted; the surrounding text is passed through unchanged.
Yes. Output is split so that no encoded-word exceeds 75 characters, and continuation lines start with a space (folding), which is the form a header value takes.