Decode =?ISO-2022-JP?B?…?= and other MIME encodings
A Japanese subject line that arrives as =?ISO-2022-JP?B?GyRC…?= is not corrupted — it is just wearing its transport encoding. This takes it off, and puts it back on when you need to write one.
- Runs entirely in your browser
- Works offline
- No upload
- No sign-up
- No watermark
Loading the tool…
How it works
- Paste the header, the body part, or a single =?…?= word.
- Press Decode; each encoded word is listed with its charset.
- To go the other way, type the text in the encode box below.
Why nothing is uploaded
Every operation on this page is done by code running inside your browser tab, using the same engine that renders web pages. The file is read from disk into your tab’s memory, transformed there, and written back out as a download. It is never sent anywhere — not to us, not to a third party.
Verify it yourself
- Open your browser’s developer tools (F12) and select the Network tab.
- Load your file and run the tool.
- The only requests you will see fetch the tool’s own code — and, for a few heavy tools, their open-source engine from a public CDN — plus one small page-view ping to loreatec.jp (page address and title, nothing more). None of them carry your file.
Frequently asked questions
What is an encoded word?
E-mail headers are, by the original standard, ASCII only. RFC 2047 works around that by wrapping non-ASCII text in =?charset?encoding?text?=, where the encoding is B (base64) or Q (a quoted-printable variant). Every mail client decodes it for display, which is why you normally never see it — until something shows you the raw header.
Should I still use ISO-2022-JP?
For headers going to Japanese mobile carriers and genuinely old systems it remains the safest choice. But it cannot represent ①, ㈱, ～, half of the symbols people paste from Word, or any emoji: those arrive as ? or vanish. UTF-8 carries everything and is accepted by every modern receiver, including all three carriers today.
Why does the encoder only offer UTF-8?
Because browsers can decode ISO-2022-JP, Shift_JIS and EUC-JP but cannot encode to them — TextEncoder only produces UTF-8. Offering those options and quietly returning UTF-8 would be exactly the kind of silent wrongness this tool exists to expose. Decoding supports all of them.
B or Q?
For Japanese, B: almost every byte would need escaping in Q, so base64 is shorter. For text that is mostly Latin with a few accents, Q keeps the header readable, which helps when you are reading raw source.