IDNA domain encoder
münchen.example.com becomes xn--mnchen-3ya.example.com: each label with accents or another script gets its xn-- form, while plain ASCII labels stay as they are. Decode the other way to read a hostname from a log or mail header. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- münchen.example.com
- Calculation mode
- Encode
- Result
- xn--mnchen-3ya.example.com
- Ascii
- xn--mnchen-3ya.example.com
- Unicode
- münchen.example.com
- Label count
- 3
Internationalized domain names let brands, cities, and personal names appear in native scripts on the public internet, but the Domain Name System still carries labels as ASCII-compatible encodings. IDNA (Internationalized Domain Names in Applications) maps each Unicode U-label to an A-label that begins with xn-- and carries RFC 3492 Punycode, then reverses the mapping so operators can read the intended name again. This capability accepts a full multi-label hostname—not only a single label—and converts either direction with a simple mode field: encode for ToASCII, decode for ToUnicode. Pure ASCII labels pass through unchanged; mixed names such as a city label plus a classic TLD are handled label by label.
Encode a Unicode hostname to IDNA ASCII (ToASCII / xn--)
The engine splits the hostname on dots, folds each label in a locale-independent way, and processes labels independently so a mixed name such as a non-ASCII left label beside an ASCII right label is converted without forcing the whole string through a single encoder. Pure ASCII LDH labels pass through unchanged without an xn-- prefix, matching IDNA practice for names that never needed internationalization.
When a label contains any non-ASCII code point, the engine runs the RFC 3492 Punycode encoder and prefixes the result with xn-- to produce the A-label used in DNS zone files, certificate SANs, reverse-proxy host rules, and WHOIS-style displays. Labels that already look like ACE forms are validated by decode-and-re-encode round-trip so a hand-edited xn-- string fails closed instead of being trusted blindly. Identical inputs always produce identical outputs because the path is pure arithmetic with no network, no random salt, and no wall clock.
Use this path when you need a paste-safe ASCII hostname for a migration checklist, a zone-file line, an ACME SAN entry, or a support ticket that must survive systems that only accept ASCII hostnames. DNS enforces a sixty-three octet limit per label and a two-hundred-fifty-three character limit on the assembled ASCII hostname; this engine checks both so oversized international names fail early rather than producing non-deployable strings.
Trailing-dot FQDN notation is preserved when present, while leading dots, consecutive dots, schemes, paths, ports, and userinfo are rejected so the SEO landing stays focused on bare domain conversion.
What you can do with it
DNS zone and certificate prep
Encode Unicode brand or city hostnames to xn-- ASCII form before writing zone files, ACME SAN lists, or reverse-proxy host rules that only accept ASCII.
Support and log readability
Decode ACE hostnames from mail headers, certificate transparency logs, and ticketing systems back to readable Unicode for agents and customers.
FAQ
How do I convert a Unicode domain to IDNA ASCII?
The result field returns the ASCII form such as xn--mnchen-3ya.example.com.
How do I decode an xn-- hostname back to Unicode?
Set mode to decode and put the ACE hostname in text. The result field returns the Unicode form when every label is valid.
What happens on an invalid IDNA label?
The message names the label position and reason (empty xn-- body, bad Punycode, empty labels, length limits). Failures are not charged.
Is the IDNA domain encoder free?
The browser tool runs free on your device.
Can I convert a full multi-label hostname?
Yes. Unlike single-label Punycode tools, this capability accepts multi-label domains and converts each label under IDNA rules, returning both ascii and unicode views.
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/idna \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"münchen.example.com"}'const res = await fetch("https://api.kit.forhosting.com/enc/idna", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "münchen.example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/idna",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "münchen.example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/idna", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"münchen.example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"münchen.example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/idna", 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": "münchen.example.com"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.idna",
"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
Empty ACE bodies, truncated Punycode, illegal characters, consecutive dots, schemes, paths, and DNS length violations fail with invalid_input that names the offending label index instead of silently corrupting the string.
Encode a Unicode hostname to IDNA ASCII (ToASCII / xn--)
Send a JSON body with the required string field text set to a full internationalized domain name—for example a city brand with an umlaut followed by a classic second-level and top-level domain—and leave mode at its default encode or set mode to encode explicitly. The response includes result (the full ASCII hostname), ascii (same wire form), unicode (the folded Unicode view), label_count, has_ace true when any label used ACE, mode encode, and method idna so tests can pin every field.
Decode ACE hostnames back to Unicode and report invalid labels
Set mode to decode and put an ASCII or mixed ACE hostname such as xn--mnchen-3ya.example.com into text. The engine walks each label, strips a leading xn-- prefix when present, validates that the body uses only the basic alphabet of letters, digits, and internal hyphens, then runs the RFC 3492 decoder to recover Unicode code points—including supplementary-plane characters represented with surrogate pairs in JavaScript strings. Pure ASCII non-ACE labels pass through on decode, and Unicode labels already present in a mixed hostname are accepted and re-derived to ASCII in the ascii field so the response always offers both views. Prefer this capability when your search intent is an IDNA domain encoder or decoder for full hostnames; single-label Punycode body experiments and live DNS resolution belong to other tools. After decoding a label it re-encodes and requires an exact round-trip against the body so truncated or hand-edited ACE strings fail closed with invalid_input instead of returning plausible but wrong glyphs. Empty bodies after xn--, illegal characters such as punctuation bangs, overflow conditions, empty labels from consecutive dots, and labels that exceed DNS length limits all raise a descriptive invalid_input message that includes the one-based label position so bulk tooling can highlight the bad segment. Successful decode returns result and unicode as the readable U-label form, ascii as the wire form, label_count, has_ace true when any ACE was present, mode decode, and method idna. Failed validation is not charged on the prepaid API after the engine rejects the request, which keeps exploratory decode of suspicious log lines inexpensive while still protecting balance against silent success on garbage input.
API usage, pricing, DNS workflows, and practical limits
Process full hostnames in one call—the multi-label design is intentional so SEO and product intent match “IDNA domain encoder” rather than forcing clients to split and rejoin labels themselves. Do not send full URLs: strip the scheme and path first, and convert only the bare hostname so the contract stays narrow and the error messages stay actionable. When a label fails, fix that label and resubmit; partial success is never returned, which keeps client code simple and avoids half-converted hostnames leaking into production DNS. Call the free in-browser IDNA domain encoder for support playbooks, classroom demos, and one-off hostname checks without installing OpenSSL s_client tricks or language runtimes. Use the prepaid KIT API when a backend, registrar panel, certificate automation job, mail gateway, or SDK needs the same encode or decode step under balance at $0.002 per successful item; validation failures never consume balance after the engine rejects the request. A typical workflow encodes a Unicode brand hostname before writing A-labels into a zone template or reverse-proxy server_name list, then decodes ACE names copied from mail headers, certificate transparency logs, or ticket subjects so operators can read the intended U-labels. Authors shipping SDKs can map the result field into a copy button while ascii, unicode, label_count, and has_ace make OpenAPI examples self-explanatory for readers learning IDNA for the first time.
Integration use cases
Docs and CI golden checks
Pin encode and decode fixtures for multi-label IDNA names so documentation samples and continuous-integration tests fail fast if ACE handling ever drifts.