Modified UTF-7 IMAP encoder
Get the exact folder name an IMAP server expects: Inbox/日本語 becomes Inbox/&ZeVnLIqe-, and a cryptic token from a protocol log decodes back into its readable label. Names in plain English stay unchanged. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- Inbox/日本語
- Calculation mode
- Encode
- Result
- Inbox/&ZeVnLIqe-
- Encoding
- modified_utf7_imap
- Input length
- 9
- Output length
- 16
IMAP mailbox names on the wire use a dialect of UTF-7 called modified UTF-7 (RFC 3501 section 5.1.3). Printable US-ASCII characters except the ampersand keep their ordinary form, a lone ampersand becomes the two-character sequence ampersand-hyphen, and every other character—accents, CJK, emoji, and control codes—is packed as UTF-16BE inside a modified Base64 section that starts with ampersand and ends with hyphen, with slash replaced by comma. This tool encodes a human Unicode folder name into that wire string or decodes a LIST/SELECT response back to readable text.
What IMAP modified UTF-7 is and what this converter returns
Standard mailbox protocols still exchange folder names as 7-bit-safe strings even when users create labels in Japanese, Spanish, Arabic, or emoji. IMAP solved that with modified UTF-7 rather than raw UTF-8 on every server path: the name stays mostly readable when it is pure English, while international segments become compact ampersand-wrapped blocks. The encoding rules are strict.
Characters in the range space through tilde, except ampersand, are written unchanged. Ampersand itself is never left bare; it is always written as ampersand followed by hyphen so parsers can treat a following Base64 block as a deliberate shift. Any character outside that direct set is collected into a run, converted to big-endian UTF-16 code units, then Base64-encoded with the classic alphabet except that the sixty-fourth symbol is comma instead of slash, and padding equals signs are omitted.
Encode mode returns that wire string plus the resolved mode, a fixed encoding label, and input and output lengths.
Where mailbox-name encoding fits in mail clients, servers, and tests
Client authors meet modified UTF-7 when they implement CREATE, RENAME, LIST, or LSUB and need the on-the-wire name to match what Dovecot, Cyrus, Exchange, or Gmail expect for international folders. Support engineers paste a cryptic folder token from a protocol log and need the human label without opening a desktop client. Backend services normalize user-facing folder titles before storing them in an IMAP proxy or before comparing SELECT targets in integration tests.
Quality engineers generate encode and decode pairs for contract tests so a library upgrade cannot silently change comma-versus-slash Base64 or drop ampersand escaping. Educators use the same page when teaching the difference between UTF-8 mailbox extensions, legacy modified UTF-7, and display names that never hit the wire. Pair it with other free encoders in the catalog when you are building a small lab of deterministic text tools for mail and MIME work.
What you can do with it
IMAP client and server debugging
Encode Unicode folder names for CREATE or SELECT, or decode LIST responses that contain ampersand-wrapped modified UTF-7 segments.
Support log translation
Turn cryptic wire mailbox tokens from protocol traces back into readable Unicode labels without a full mail client.
FAQ
How is IMAP modified UTF-7 different from ordinary UTF-7?
IMAP uses ampersand as the shift character instead of plus, and the Base64 alphabet uses comma instead of slash. Ampersand itself is written as ampersand-hyphen. Padding equals signs are omitted.
What does encode mode return for plain ASCII?
The same printable ASCII string, because direct US-ASCII characters except ampersand represent themselves. Only non-direct characters and bare ampersands are rewritten.
How is a literal ampersand encoded?
As the two-character sequence ampersand-hyphen (&-). That keeps shift parsing unambiguous when a real Base64 section follows later in the name.
How do I read a folder name like Inbox/&ZeVnLIqe- from a log?
Choose decode and paste the name as it appears. Each section between an ampersand and a hyphen turns back into its characters, so Inbox/&ZeVnLIqe- reads Inbox/日本語 again.
Why would a modified UTF-7 folder name fail to decode?
It fails when a final ampersand has no closing hyphen, a section holds anything other than letters, digits, plus and comma, a section is empty, or non-ASCII characters sit outside a section. The tool reports the problem instead of guessing.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/utf7-imap \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Inbox/日本語"}'const res = await fetch("https://api.kit.forhosting.com/enc/utf7-imap", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "Inbox/日本語"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/utf7-imap",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "Inbox/日本語"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/utf7-imap", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"Inbox/日本語"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"Inbox/日本語"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/utf7-imap", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "Inbox/日本語"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.utf7_imap",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
The algorithm is fully deterministic, runs entirely in your browser for free, and reports malformed shift sequences, bad Base64, and illegal bare non-ASCII with invalid_input instead of guessing. Successful API calls cost $0.002 each; validation failures are not charged.
What IMAP modified UTF-7 is and what this converter returns
Decode mode reverses the path: it copies direct ASCII, expands ampersand-hyphen to a single ampersand, and turns each ampersand-payload-hyphen section back into Unicode.
How text and mode are validated and when requests fail
Encode accepts any well-formed Unicode string up to the documented character limit, walks code units carefully so surrogate pairs for non-BMP characters stay together, and rejects unpaired surrogates instead of emitting corrupt Base64. Empty Base64 sections between ampersand and hyphen are rejected because the only legal empty shift is the dedicated ampersand-hyphen literal for a single ampersand. The required field is text, with aliases input, value, and s so forms and scripts can reuse existing column names. Mode defaults to encode and accepts decode; aliases op, direction, and action map to the same switch. Decode requires a well-formed modified UTF-7 string: an ampersand at the end of the input without a closing hyphen, a Base64 payload that contains characters outside A–Z a–z zero–nine plus and comma, a payload that decodes to an odd number of bytes, or non-ASCII characters sitting outside a shift section all fail with invalid_input and a precise English message. The entire path avoids Date, random numbers, and network I/O, which keeps browser demos, CI goldens, and API responses bitwise identical for the same input. Failed validation is not billed, so you can probe bad LIST lines cheaply while successful transforms stay at $0.002 per item.
Where mailbox-name encoding fits in mail clients, servers, and tests
On this page the conversion runs free in the browser; through the API each successful request costs $0.002, nothing is stored after the response, and the mathematics match the RFC examples such as the classic Taipei and Japanese path that becomes a sequence of ampersand-wrapped modified Base64 segments.
Integration use cases
Protocol fixture generation
Produce reproducible mailbox-name pairs for unit tests, golden files, and IMAP integration checks across locales.
Technical questions
What errors cause invalid_input?
Unterminated ampersand shifts, illegal Base64 characters, odd-length decoded byte runs, unpaired surrogates, bare non-ASCII outside a shift section, and missing text. Failed calls are not charged.
How much does the API cost?
$0.002 per successful request. The in-browser tool is free. Invalid input is not charged.