The Unfinished Business of IDNs

That matters because this is not some obscure edge case from beyond the supposed “mainstream” internet. This sits inside the linguistic reality of the EU itself. A European platform that cannot handle Latin diacritics, Greek, or Cyrillic is not merely failing some decorative internationalisation test. It is failing to support the scripts of the political and legal community within which it operates.

Technically, this problem has been “solved” for a long time. Operationally, it still is not solved.

That distinction matters.

The Domain Name System itself did not become Unicode-native. Instead, IDNs were designed to work with the old ASCII-only assumptions of DNS. A Unicode label, such as the gânduri part of gânduri.paradoxical.eu is converted into an ASCII-compatible label xn--gnduri-wta.paradoxical.eu using an encoding known as Punycode. (Unicode, Punycode – see what they did there?)

The human-readable Unicode form is often called the U-label. The ASCII-compatible encoded form is the A-label. The A-label goes into DNS, TLS certificates, HTTP requests, logs, redirects, caches, search systems, and every other place where some software component wants a hostname and may or may not know what non-ASCII characters are.

So the core trick is elegant: let humans use Unicode while keeping the DNS wire format compatible with existing infrastructure. No root-and-branch replacement of DNS was required. No apocalypse. No global flag day. No need to persuade every resolver on earth to become Unicode-aware overnight.

That was introduced in 2003. And yet, after all this time, IDNs still break things.

The reason is that DNS compatibility was only the first problem. It may even have been the easy problem, and we’re great at solving easy problems and declaring Job Done. The harder problem is that domain names are not used only by DNS. They are used everywhere: browsers, CMS platforms, redirect engines, certificate issuers, search crawlers, analytics systems, spam filters, web forms, APIs, databases, email systems, password managers, logs, support tools, validation libraries, and user interfaces.

Every one of those components has to accept, validate, store, process, compare, display, and transmit the name correctly. If any one of them assumes that a domain name is only [a-z0-9.-], the chain breaks.

When we get into reputational scoring, things get even more complex when domain names have multiple representations. Without software being aware of this, all sorts of problems naturally arise.

DNS is solved; the application stack is not

These are not fake domains in some toy namespace; .ελ is the Greek-script country-code top-level domain for Greece. .ευ is the Greek-script country-code top-level domain for the European Union. At the registry and DNS layer, this is not an exotic fantasy. It is part of the modern root zone.

The trouble begins when the names rise above DNS and have to pass through the web stack.

“My name is Legion, for we are many”

A browser must decide whether to display the Unicode form or the Punycode form. A CMS must decide what it stores as the site URL. A redirect layer must decide what is canonical. A sitemap generator must emit URLs. A search crawler must follow them. A certificate authority must issue certificates. A platform’s domain connection screen must validate the input. An email provider must decide whether it supports the domain part, the mailbox part, or both. Security systems must decide whether the name is suspicious, and we’re back at reputations.

Each layer is a place for the same domain to be treated as one of several different strings:

      Original URL: gânduri.paradoxical.eu
      Punycode URL: xn--gnduri-wta.paradoxical.eu
         Alias URL: ganduri.paradoxical.eu
SaaS site internal: xngnduriwtaparadoxical.wordpress.com

Those may be semantically related in the mind of the site owner. They may even resolve to the same content. But to many systems they are separate URLs, separate hosts, separate cache keys, separate canonical candidates, separately assessed for reputation, and separate opportunities to make a mess of things.

Gânduri Eclectice – Eclectic Thoughts Blog

Let’s stick with my example above, the example of this very blog. In theory, that should be manageable. The domain with the Romanian diacritic is the nice human-facing form. The Punycode form is the technical representation. The plain ASCII form is a compatibility alias. The SaaS site internal representation is WordPress.com’s internal name which should be invisible under normal use.

In practice, things became stranger.

The site itself was reachable, and individual article pages could be found. But crawler-like access behaved differently depending on which form was used as the starting point. The diacritic and Punycode forms appeared to lead through awkward WordPress.com internal backing hostnames and redirects. Some links went via the generated WordPress.com hostname rather than the intended custom domain. Worse, some redirect paths downgraded from HTTPS to HTTP, which strict crawlers quite reasonably refused to follow.

That is not a DNS failure. The domain resolved. The site existed. The content was there. The failure was higher up: canonical host handling, redirects, homepage structure, platform-generated links, and crawler behaviour.

Changing the plain ASCII alias ganduri.paradoxical.eu into the new base domain has helped. Making the opening page list articles directly also helped. A crawler landing at the root can now see post links immediately, instead of having to follow a navigation route through platform-generated links and redirects.

That is a good workaround. It is also an indictment.

An IDN website should not need an ASCII compatibility domain and a redesigned homepage simply to become reliably crawlable. If the point of IDNs is to let people use meaningful non-ASCII names, it is a little absurd if the practical advice remains: “Use the lovely Unicode domain in conversation, but make the actual address plain ASCII.”

WordPress is not WordPress.com

There is an important distinction between WordPress, the open-source CMS, and WordPress.com, the hosted platform.

The open-source WordPress ecosystem has had some level of IDN support, and Universal Acceptance testing has found reasonable support for IDNs in WordPress and various plugins, though with weaker results around fully internationalised email addresses.

WordPress.com is a different matter. WordPress.com’s own support material currently says that Internationalised Domain Names are not supported for certain domain operations, including connection/mapping. Its troubleshooting guide explicitly lists IDNs as a cause of domain-mapping failure.

That matches my experience when trying to add βαζκερνιλλε.ευ and its Punycode form xn--mxabkadtfkar7b.xn--qxa6a to WordPress.com. The domain is valid. I own it. The TLD is real. The Punycode is correct. WordPress.com still rejects it.

This is the most dispiriting sort of failure because it is not a standards problem. It is a product support problem. The internet standard permits the thing. The registry permits the thing. DNS can publish the thing. But a major hosted website platform says no.

For a personal blog, that is irritating. For the wider internet, it is more serious. If large platforms do not support IDNs, then IDNs remain second-class citizens. A domain can be technically valid but practically unusable.

Who cares? Hardly anyone is really affected, right?

How about the actual numbers. Depending on how strictly one counts, only about 8% of humanity lives in a primary written-language environment that is comfortably ASCII-only. Roughly half the world has a normal non-Latin writing system, and another third uses Latin script with at least some non-ASCII characters.

So when platforms treat IDNs, EAI, Unicode names, or non-ASCII URLs as exotic edge cases, they are really saying:

“We optimised for a minority of the planet and then acted surprised when the rest of humanity turned up.”

Astonishingly, most of the rest of humanity has indeed turned up. Summary table below, more detailed version at the end of the article.

Category	Approx Range: world population	Approx Range: world internet users
Only ASCII exclusively	6–10%	7–10%
Mostly ASCII, some diacritics	13–18%	17–22%
Latin script, lots of diacritics/special letters	18–23%	19–24%
Non-Latin script	53–60%	46–56%

The internet-user split is less non-Latin-heavy than the world-population split because connectivity is still uneven. The ITU says 2.2 billion people remain offline, disproportionately in lower-income countries, which includes many countries with non-Latin or heavily marked Latin scripts. (ITU)

Why the non-Latin number is so large

The biggest contributors are obvious once listed: China, India, the Arabic-script world, Bangladesh, Pakistan, Cyrillic-using countries, Japan, Korea, Iran, Thailand, Ethiopia, Nepal, Sri Lanka, Israel, Greece, Armenia, Georgia, Myanmar, Cambodia, Laos, and so on. China and India alone now account for an enormous share of global internet users, with recent Digital 2026-derived rankings putting China at about 1.30bn internet users and India at about 1.03bn. (Visual Capitalist)

Ethnologue’s 2026 language list also gives the shape of the problem: English, Mandarin, Hindi, Spanish, Arabic, French, Bengali, Portuguese, Indonesian, Urdu, Russian, Japanese, Vietnamese, Telugu, Tamil, Korean, Thai, Gujarati, Kannada and others are all vast communities, but many of those are normally written in non-Latin scripts. (Wikipedia)

Search engines and crawlers

A website URL is not very useful if search engines, social previews, archivers, AI crawlers, and link unfurlers cannot reliably crawl it.

Search engines do understand a lot about canonicalisation. They can deal with duplicates, redirects, HTTP versus HTTPS, sitemaps, and canonical link annotations. But they do not owe any site owner perfect interpretation of a confused URL graph.

If the same content appears under multiple domain names, and some of those forms redirect through HTTP, platform hostnames, or stale templates, then the crawler has to decide what is canonical, what is duplicate, what is unsafe, and what is worth crawling. Google says canonical hints are hints, not commands. The crawler can choose differently from the site owner.

That is not specifically an IDN problem, but IDNs multiply the number of possible representations. Add a Unicode form, a punycode form, an ASCII alias, and a hosted-platform backing hostname, and a simple blog can accidentally acquire the URL topology of a minor railway network.

The safest pattern for crawling remains painfully boring:

• one canonical HTTPS hostname
• clean redirects
• same-origin internal links
• sitemap using the canonical host
• robots.txt available on the canonical host
• homepage exposes article links directly

That is true for all websites. With IDNs, it becomes non-negotiable.

Browsers are not the whole internet

It is tempting to test IDNs in a browser and declare success. The browser shows the site. The address bar looks plausible. The certificate works. The page loads.

That is not enough.

Browsers contain a great deal of special IDN handling. They may display Unicode for some domains and Punycode for others, depending on security policy, script mixing, user locale, confusable characters, and phishing risk. Chrome’s documentation is explicit that browsers are balancing usability for non-Latin-script users against homograph attacks, where different Unicode characters can look deceptively similar.

So the browser is not simply “showing the truth”. It is making a policy decision about what is safe and intelligible to display.

Crawlers, validators, CMS tools, and hosting dashboards may make different decisions. A browser may tolerate a redirect chain that a crawler rejects. A human may click through a visible menu that a bot treats as duplicate or unsafe. A browser may upgrade HTTP to HTTPS in ways that a strict fetcher will not. A logged-in admin may see a different state from a public crawler.

This is why “it works in my browser” remains one of the least satisfying sentences in computing; now more than ever, perhaps.

Security: the unavoidable homograph problem

Some of the caution around IDNs is justified.

Unicode contains characters that look identical or nearly identical across scripts. A Latin a and a Cyrillic а can be visually indistinguishable. Whole domains can be constructed to look like familiar brands while being different strings. This is the IDN homograph problem.

There is a difference between baskerville.ελ and βαζκερνιλλε.ευ; the first is mixed at the domain level: a Latin second-level label with a Greek-script TLD. The second is fully Greek-script. Security systems may treat those differently. The fully Greek-script domain may be less visually mixed, but it is still non-ASCII throughout, and therefore more likely to expose weak support in software stacks.

A good IDN is not necessarily unsafe. But every IDN enters a world where security heuristics, anti-phishing rules, and old validators are constantly second-guessing it.

Safe and unsafe use cases

Not all IDN use is equally risky.

Relatively safe: human-facing aliases

An IDN can work well as a memorable, human-facing alias that redirects to a plain ASCII canonical domain. This lets the IDN serve as a meaningful or playful public doorway while the crawling, canonicalisation, analytics, and platform hosting remain on the boring address.

The redirect must be clean:

• HTTPS → HTTPS
• single hop if possible
• no HTTP downgrade
• no platform hostname detour

This is probably the safest way to use an expressive IDN today.

Relatively safe: email domain part, where the provider supports it

I have had good results using IDNs for email, especially where the local part remains ASCII and only the domain part is internationalised.

For example, a mailbox like robert@baskerville.ελ is a less ambitious case than björk@baskerville.ελ; the first uses an internationalised domain but keeps the mailbox name ASCII. The second requires support for Email Address Internationalisation in the local part as well.

Email is complicated, but in some respects it is more explicit about capability. Email Address Internationalisation (EAI) relies upon the SMTPUTF8 extension (defined in RFC 6531) and related changes across the mail path. If the sending and receiving infrastructure supports it, it can work well. If not, it should fail clearly or require an ASCII alias.

That makes email oddly more honest than the web. A web platform may half-accept an IDN and then generate broken redirects. Mail systems are more likely to expose whether the path really supports internationalisation.

Riskier: IDN as the sole canonical website address

Using an IDN as the only canonical website address is still risky if the site depends on hosted platforms, SEO, social sharing, analytics, AI crawlers, and broad compatibility.

The risk is not that the domain cannot resolve. The risk is that one or more of the following will fail:

• domain connection UI
• certificate provisioning
• redirect generation
• canonical URLs
• sitemaps
• robots.txt
• internal links
• crawler access
• social preview fetching
• analytics attribution
• security filters
• support tooling

This is especially true if both the second-level domain and the TLD are IDN labels, as with βαζκερνιλλε.ευ. The domain may be more linguistically coherent, but it is also a stronger test of every component’s Universal Acceptance readiness.

Riskier: mixed-script or confusable domains

Mixed-script domains and visually confusable names are more likely to trigger browser or security-tool caution. That does not make them inherently malicious, but it does make them operationally fragile.

A domain like baskerville.ελ is not pretending to be someone else, but it combines a Latin label with a Greek-script TLD. Some systems will handle that beautifully. Others will reach for punycode. Some may reject it. Some may store it correctly but display it inconsistently. A legitimate owner may understand the cultural or aesthetic intent. A regex does not.

Historically, many IDNs have a Latin TLD, because the first IDN TLDs were not introduced until 2010-05-05, when these three Country-Code Top-Level Domains (ccTLDs) were launched:

• .مصر, xn--wgbh1c, Egypt, Arabic script (right-to-left)
• .السعودية, xn--mgberp4a5d4ar, Saudi Arabia, Arabic (right-to-left)
• .امارات, xn--mgbaam7a8h, UAE, Arabic script (right-to-left)

There are now around 150 IDN TLDs, including both ccTLDs and Generic TLDs (gTLD). See the table in the references section at the end if interested.

Safest: ASCII canonical plus IDN decoration

For now, the most robust pattern is:

• ASCII canonical domain for infrastructure
• IDN domain for identity, display, and redirect

This is emotionally unsatisfying, because it concedes too much to broken tooling. But it works.

The IDN can still matter. It can appear on business cards, in articles, in email signatures, on social profiles, and in conversation. It can be a doorway. It can be a statement. It can be beautiful.

But if discoverability matters, let the crawlers eat plain ASCII.

The failure is cultural as much as technical

The most frustrating part of IDN support is that it is not a new idea. This is not a bleeding-edge protocol being asked to work on day one. IDNA2008 is old enough to drive. Email internationalisation has had standards for years. ICANN and the Universal Acceptance Steering Group have been talking about this for a decade.

And still, major systems fail in ordinary use.

A domain containing â should not be exotic. Greek-script TLDs should not be surprising. Major public platforms should not fail to understand IDNs and display Punycode URLs (yes, looking at you, LinkedIn). A website platform should not reject a valid domain simply because the letters are not ASCII. A crawler should not require the site owner to reverse-engineer redirect chains to discover why articles are not being followed (yes, looking at you, WordPress.com).

Non-ASCII character support was the intent. Not a bonus. Not an edge-case indulgence. Not a decorative flourish for standards documents. The point was to let the internet exist in the scripts people actually use.

If an IDN can be registered but not hosted, linked but not crawled, displayed but not validated, emailed but not accepted by forms, then Universal Acceptance has not been achieved. We have not built a multilingual internet. We have built a multilingual sign above a Latin-script-only door.

Practical advice for using IDNs now

My current practical advice is as follows.

First, always know the Punycode form of the domain. Treat it as the technical identity. Use the Unicode form for humans, but test the A-label everywhere.

Second, keep one canonical hostname. Do not let the same site float between Unicode, Punycode, ASCII alias, and platform backing domains. Choose the canonical address deliberately.

Third, make every redirect HTTPS-only. An HTTPS-to-HTTP downgrade is enough to make strict crawlers stop, and rightly so.

Fourth, make internal links boring. Same-origin relative links or absolute links to the canonical HTTPS hostname are best. Do not rely on a hosted platform’s backing domain. Yes, look ashamed WordPress.com.

Fifth, submit sitemaps using the canonical host. Do not make crawlers guess.

Sixth, test with more than a browser. Use curl, Google Search Console, Bing Webmaster Tools, social card validators, email validators, and whatever crawler or AI-fetch tools matter to the site.

Seventh, if using WordPress.com, assume IDN custom domains may be rejected or behave inconsistently. Self-hosted WordPress may offer more control, but then the responsibility moves to your own stack.

Eighth, for email, distinguish between “IDN in the domain part” and full EAI with Unicode in the mailbox name. The first is often more widely usable. The second is more demanding.

Finally, do not delete a working legacy IDN mapping on a hosted platform unless you are prepared for the possibility that you cannot add it back. Sometimes the only thing holding a configuration together is that it was accepted before the validator learned to say no.

In Summary

IDNs are a good idea. The standards work is clever. The DNS compatibility model is sound. The need is obvious. People should be able to use the internet in their own languages and scripts.

But a website is more than DNS.

A website is redirects, certificates, sitemaps, robots files, crawlers, CMS templates, canonical tags, caches, validators, browser display policies, social previews, analytics tools, search indexes, and support desks. IDNs have to survive all of that.

Too often, they do not.

So yes, internationalised domain names work. Except when the hosting platform rejects them. Except when the crawler will not follow them. Except when the CMS emits the wrong canonical URL. Except when the redirect downgrades to HTTP. Except when the browser displays Punycode. Except when a form validator refuses the address. Except when the support article says the valid domain is not supported.

That is the melancholy state of IDNs after all these years: DNS solved the problem it was asked to solve, and then the rest of the internet failed to finish the job.

IDN Risk 2026

Detailed table covering specific platform support is in the references section. Just a risk summary here. The annoying truth:

Use case	Current risk
Typing an IDN into a modern browser	Low
Google crawling a well-configured IDN site	Low to medium
Posting an IDN link on social media	Medium
Having the link display prettily as Unicode	Medium to high
Using an IDN in profile website fields	Medium to high
Using an IDN as a hosted-platform custom domain	High
Using IDN email domain only, with ASCII mailbox name	Often workable
Full EAI email with Unicode local part	Still risky
Expecting every platform to treat it as normal	Touchingly optimistic, like putting faith in printer drivers

The best evidence base is still depressingly broad rather than platform-specific. ICANN/UASG define Universal Acceptance as all valid domain names and email addresses working across internet applications; their recent reports still document gaps across programming languages, email tools, identity platforms, web hosting, and websites. (ICANN)

For social platforms, UASG’s 2021/2022 testing found a split: registration/login with internationalised email addresses was poor, but once users were authenticated with ordinary credentials, most networks showed much better readiness for posting IDN URLs and email addresses. (Idn World Report)

Practical ranking

Best bets: Google Search, Reddit, Mastodon, Telegram, Discord, Slack, GitHub Pages using punycode, self-hosted WordPress done carefully.

Usable but ugly: Facebook, Instagram, YouTube, LinkedIn, Pinterest, Bluesky.

Likely to annoy you: WordPress.com custom domains, LinkedIn visual display, TikTok bio/link validation, any platform where the URL has to pass through a marketing-profile field rather than normal post text.

Most reliable public strategy: use an ASCII canonical domain for crawling and platform forms, then use the IDN as a human-facing alias or redirect. Yes, this is a betrayal of the dream. The dream has not yet shipped, sorry.

Sources, References, Additional Details

Estimated Latin/non-Latin split by everyday writing-system need

My best defensible estimate, not a laboratory measurement. It’s a complex matter, and my groupings are arbitrary. It makes the point, however.

I’m using roughly 8.30 billion world population in mid-2026 and about 6.0 to 6.04 billion internet users. The ITU put global internet use at about 6 billion people in 2025, and DataReportal’s Digital 2026 says internet users had passed 6 billion, about 73.2% of world population. UN-based mid-2026 world population estimates are around 8.30 billion. (ITU)

Category	People	% of world	Internet users	% of users	Examples
Only ASCII exclusively	~0.65bn	~8%	~0.50bn	~8%	Indonesian/Malay, Swahili, Somali, isiZulu/isiXhosa-style ASCII Latin orthographies, much Filipino/Tagalog in practice, many Latin-script African and Austronesian contexts where diacritics are absent or routinely ignored
Mostly ASCII, may include some diacritics	~1.25bn	~15%	~1.20bn	~20%	English with naïve, façade, fœtus, fête, rôle; German (ß but often written as double s), Dutch, Italian, Welsh, Scandinavian languages, Irish in many everyday digital contexts
Latin script, lots of diacritics/special letters in everyday use	~1.65bn	~20%	~1.30bn	~22%	French, Spanish, Portuguese, Romanian, Vietnamese, Turkish, Polish, Czech, Slovak, Hungarian, Baltic languages, Balkan Latin orthographies, Māori, Yoruba when written fully
Non-Latin script as a normal writing system	~4.75bn	~57%	~3.05bn	~50%	Mandarin/Hanzi, Japanese Kanji/Kana, Korean Hangul, Cyrillic, Arabic, Persian, Urdu, Hebrew, Devanagari, Bengali, Gurmukhi, Gujarati, Tamil, Telugu, Thai, Greek, Ethiopic, Armenian, Georgian, Tifinagh, and many others

First TLD IDNs in order of creation

On 5 May 2010, the first production IDN ccTLDs in the DNS root were Arabic-script TLDs for Egypt, Saudi Arabia, and the UAE.

The table below is a chronological milestone table, not all 151 current IDN TLDs row-by-row. As of ICANN’s June 2025 IDN report there were 151 delegated IDN TLDs: 61 IDN ccTLDs and 90 IDN gTLDs on IANA’s current TLD list. (ICANN)

Notes to table of IDNs

1. The 2007 IDN test TLDs are excluded here. They existed for testing, but this includes production IDN TLDs only.
2. “Registration date” means the IANA root-zone registration date shown on the delegation page, not necessarily the public sunrise/general-availability date.
3. Some delegated IDN gTLDs later changed operator, were retired, or show “not assigned” in IANA’s current database. The current total of 151 delegated IDN TLDs is therefore the useful “today” figure.

Date first in root zone	IDN TLD(s)	Punycode / A-label	Type	Script / language	Notes
2010-05-05	.مصر	xn--wgbh1c	ccTLD, Egypt	Arabic	One of the first three production IDN TLDs ever delegated.
2010-05-05	.السعودية	xn--mgberp4a5d4ar	ccTLD, Saudi Arabia	Arabic	One of the first three
2010-05-05	.امارات	xn--mgbaam7a8h	ccTLD, UAE	Arabic	One of the first three
2010-05-12	.рф	xn--p1ai	ccTLD, russian Federation	Cyrillic	First Cyrillic IDN ccTLD
2010-07-12	.香港	xn--j6w193g	ccTLD, Hong Kong	Han / Chinese	Early Chinese-script IDN
2010-07-14	.台湾, .台灣	xn--kprw13d, xn--kpry57d	ccTLD, Taiwan	Han / Chinese, simplified and traditional	Variant-script handling becoming part of real root-zone
2010-08-19	.تونس	xn--pgbs0dh	ccTLD, Tunisia	Arabic	Continued Arabic rollout
2010-08-19	.ไทย	xn--o3cw4h	ccTLD, Thailand	Thai	Early non-Arabic, non-Cyrillic
2010-08-19	.ලංකා, .இலங்கை	xn--fzc2c9e2c, xn--xkc2al3hye2a	ccTLD, Sri Lanka	Sinhala and Tamil	Sri Lanka two local scripts
2010-08-20	.فلسطين	xn--ygbi2ammx	ccTLD, Palestine	Arabic	Another early Arabic-script
2010-08-20	.الاردن	xn--mgbayh7gpa	ccTLD, Jordan	Arabic
2011-02-05	.한국	xn--3e0b707e	ccTLD, Korea	Hangul	First Korean-script
2011-02-05	.ভারত	xn--45brj9c	ccTLD, India	Bengali	Part of India’s language family.
2011-10-22	.مليسيا	xn--mgbx4cd0ab	ccTLD, Malaysia	Arabic/Jawi-style form	Malaysia’s useful reminder that Arabic script is not only for Arabic-language states.
2013-10-21	.شبكة	xn--ngbc5azd	gTLD	Arabic, “web/network”	First IDN gTLD
2013-10-21	.онлайн, .сайт	xn--80asehdb, xn--80aswg	gTLDs	Cyrillic, “online” and “site”	Early IDN gTLDs in Cyrillic.
2013-12-12	.公益, .集团	xn--55qw42g, xn--3bst00m	gTLDs	Chinese, “Public welfare”, “Group”	Early Chinese-script IDN gTLDs.
2013-12-19	.在线	xn--3ds443g	gTLD	Chinese, “online”
2014-01-09	.公司	xn--55qx5d	gTLD	Chinese, “company”
2014-05-15	.موقع	xn--4gbrim	gTLD	Arabic, “site/location”
2014-07-17	.佛山	xn--1qqw23a	gTLD	Chinese, City of Foshan in Guangdong
2014-11-06	.八卦	xn--45q11c	gTLD	Chinese, “gossip”	Entertainment, celebrity news, and general gossip
2014-11-26	.հայ	xn--y9a3aq	ccTLD, Armenia	Armenian
2015-03-12	.慈善	xn--30rr7y	gTLD	Chinese, “charity”
2015-05-06	.ελ	xn--qxam	ccTLD, Greece	Greek
2015-07-02	.कॉम, .点看, .คอม	xn--11b4c3d, xn--3pxu8k, xn--42c2d9a	gTLDs	Devanagari, Chinese, Thai	Variants of .com style use.
2016-01-29	.セール	xn--1ck2e1b	gTLD	Japanese Katakana, “sale”	Japanese-script retail/marketing
2016-04-18	.ಭಾರತ .ഭാരതം .ভাৰত .ଭାରତ .بارت .भारतम् .भारोत .ڀارت	xn--2scrj9c xn--rvc1e0am3e xn--45br5cyl xn--3hcrj9c xn--mgbbh1a xn--h2breg3eve xn--h2brj9c8c xn--mgbgu82a	ccTLDs, India	Script/Language Kannada/Kannada, Malayalam/Malayalam, Bengali/Assamese, Oriya/Oriya, Arabic/Kashmiri, Devanagari/Sanskrit, Devanagari/Santali, Arabic/Sindhi	The strings have a transliteration equivalent to “Bharat”, “Bharot”, or “Bharatom”, and each have a meaning equivalent to “India”.
2016-06-24	.香格里拉	xn--5su34j936bgsg	gTLD	Chinese	Shangri-La International Hotel Management Limited
2019-07-18	.ευ	xn--qxa6a	ccTLD, European Union	Greek
2020-06-16	.ישראל	xn--4dbrk0ce	ccTLD, Israel	Hebrew	Interestingly, ten years later than Palestine’s ccTLD IDN
By June 2025	151 delegated IDN TLDs total		61 ccTLDs, 90 gTLDs	Many scripts

Major Platform Support State, 2026

None of these should be treated as “fully supports IDN” without a footnote large enough to be seen from orbit. Most platforms are somewhere between “clickable, probably” and “visually mangled, but technically alive”. LinkedIn showing Punycode is very on-brand: technically defensible, aesthetically tragic. Hang your head in shame Microsoft.

I’ve split support into three practical tests:

Link support: can you post/message an IDN URL and have it become clickable?
Display support: does it preserve Unicode, or show xn--... Punycode?
Deep support: does it work in profile website fields, link previews, crawlers, custom domains, handles, etc.?

Google explicitly says IDNs are fine for multilingual sites, provided URLs are UTF-8 and escaped properly. That is the grown-up answer. Social platforms, naturally, are more of a toddler with a chainsaw situation. (Google for Developers)

Platform	Approx scale	IDN support level	What seems to work	Problems / Notes
Google Search	Billions of users/searchers	Strong	Crawling/indexing IDN sites is officially supported if URLs are valid and linked sanely.	Canonicalisation still matters: redirects, sitemaps, HTTPS, and duplicate Unicode/punycode/ASCII aliases can confuse things. Google says IDNs are fine, but not magic. (Google for Developers)
The Facebook	c. 2.39bn ad reach; Meta family 3.56bn daily active people	Partial	IDN links generally post/click/preview.	Historically may display Punycode in previews for safety. Older Open Graph experience reports Punycode display. Meta-scale systems are not a single behaviour anyway. (DataReportal – Global Digital Insights)
Instagram	c. 1.99bn ad reach	Partial	Bio/story/post-adjacent links probably resolve if accepted.	Link fields and previews are product-specific. Past UA testing found Instagram had link/redirect acceptance issues for newer TLDs that were later fixed, which implies this has been a real class of bug. (DataReportal – Global Digital Insights)
Threads	c. 150m DAU / hundreds of millions MAU	Partial / likely Meta stack	Ordinary posted links likely behave similarly to Instagram/Facebook.	I found no clear public IDN policy. Expect Meta link-shim/canonicalisation behaviour, not a clean Unicode promise. (The Economic Times)
WhatsApp	Meta-family scale; probably 2bn+	Partial / fragile	Links in messages often become clickable.	UASG/Radix testing noted WhatsApp linkification appeared to depend on a hardcoded or outdated library. That is exactly the sort of thing that breaks IDNs and newer TLDs. (Radix)
Messenger	Meta-family scale	Partial	Links are usually clickable and previewed.	Likely shares Facebook link-shim/crawler behaviour. Unicode display not something I would trust without direct testing.
YouTube	c. 2.65bn ad reach	Partial to good	Descriptions, comments, and channel links should generally handle clickable IDN URLs.	Profile/link validation and display may normalise or punycode. Google as a web company is better than most, but YouTube product surfaces are their own little kingdoms. (DataReportal – Global Digital Insights)
TikTok	c. 2.21bn ad reach	Partial / uncertain	Links in bio/ads may accept IDN if the validator is modern.	No strong public IDN commitment found. Bio links are often tightly validated; expect inconsistent display and testing required. (DataReportal – Global Digital Insights)
Xitter	Several hundred million, exact active figure murky	Partial	The Twitter/X text stack has long had URL auto-linking machinery; IDN URLs are likely clickable through t.co.	Display may use Punycode or a shortened/link-card form. Twitter’s open twitter-text library exists specifically to identify and link URLs, but that does not provide pretty Unicode display in today’s UI. (GitHub)
LinkedIn	c. 1.43bn registered/ad-reach figure, not true MAU	Functional but ugly	Clickable links and previews generally work.	LinkedIn displays Punycode; consistent with cautious/poor UX support. DataReportal warns LinkedIn’s headline figure is registered/ad reach, not MAU. (DataReportal – Global Digital Insights)
Reddit	127m daily active uniques; 493m+ weekly active uniques	Partial to good	Markdown and bare links generally cope; previews usually fetch if the target is reachable.	App/web differences likely. Link display may depend on subreddit/app rendering and safety systems. (investor.redditinc.com)
Pinterest	631m MAU	Partial	Destination URLs for pins should work if accepted.	Preview/display may Punycode or hide host behind card UI. Needs direct test for each IDN/TLD. (Business Wire)
Snapchat	956m MAU; 483m DAU	Partial / app-dependent	Links in profiles/stories/ads may resolve.	Heavy mobile-app mediation; little public IDN-specific documentation. Treat as “test before trusting”. (investor.snap.com)
Telegram	1bn active users	Partial to good	Messages usually linkify URLs and produce previews if reachable.	Display depends on client. Unicode/Punycode handling may differ between mobile, desktop, web, and preview fetcher. (TechCrunch)
Discord	c. 200m–259m MAU estimates	Partial to good	Links and previews likely work because clients are modern and Chromiumish.	Display/security handling may vary; no strong public IDN guarantee found. (DemandSage)
Slack	c. 47m DAU estimate, 79m MAU estimate	Partial to good	Link unfurling should work when Open Graph metadata fetches cleanly.	Enterprise security/link scanners may Punycode or block. Estimates are third-party; Slack itself has historically published fewer current user figures. (DemandSage)
Bluesky	c. 42m registered; c. 27.5m MAU estimate	Partial, interestingly weird	Ordinary IDN links in posts should be feasible. Custom domain handles are domain-based.	AT Protocol handles are DNS names; the spec says “mainstream DNS” names (!) are expected, and IDN handle display remains a debated/security-sensitive area. Some apps may show Unicode, others punycode. (AT Protocol)
Mastodon / Fediverse	c. 0.75m–1m MAU for Mastodon estimates	Good but instance-dependent	Mastodon fixed IDN domain rendering issues in public HTML/API areas years ago.	Federation means instance versions vary. Some clients, old instances, or ActivityPub-adjacent tools may still show punycode or fail validation. (GitHub)
Tumblr	c. 123m–140m monthly visits, not clean MAU	Partial	Links in posts likely work.	Owned by Automattic, but not the same as WordPress.com domain mapping. Unicode display and previews need testing. (DemandSage)
Medium	Large publishing platform, user figures fuzzy	Partial / uncertain	Article links to IDNs likely work.	Custom-domain and canonical support for IDNs needs testing; no clear current public IDN policy found.
Substack	c. 20m+ monthly active subscribers	Partial / uncertain	Newsletter/post links to IDNs likely clickable.	Custom domains and email delivery are separate issues. For serious use, test web, email, Notes, previews, and redirects. (Backlinko)
WordPress.com	Major hosted publishing platform	Poor / no for connected IDN domains	Existing legacy edge cases may limp along.	Current docs say IDN registration, transfer-in, and connection are not supported. Recent support forum says even punycode versions are rejected. Head in the sand. (WordPress.com)
Self-hosted WordPress	Huge CMS ecosystem	Partial to good, depends on stack	Can usually serve IDNs if DNS, web server, TLS, WordPress config, plugins, and canonical URLs are set correctly.	Plugins/forms/email validation often fail. UASG found WordPress/plugin IDN support better than EAI support, but “better” is not “done”. (WordCamp Vienna 2026)
GitHub	180m+ developers	Partial / good if punycode	GitHub Pages supports IDN custom domains if entered as punycode.	UI requires the punycode form, not the Unicode form. Works, but not exactly lyrical. (The GitHub Blog)
GitLab	Large developer platform	Partial / historically problematic	Custom domains exist for GitLab Pages.	GitLab issue history says IDN verification “at the very least” did not work and Pages may have been broken for IDNs. Check current instance/version before trusting. (GitLab)
Cloudflare Pages / DNS	Major infra platform	Likely good at DNS, test Pages UI	Cloudflare has IDN-capable DNS libraries and generally modern DNS tooling.	Pages/custom-domain UI behaviour should still be tested. Infrastructure companies often handle DNS correctly while product UIs find new ways to be disappointing. (DeepWiki)
Netlify	Major static hosting	Partial / punycode route likely	IDN domains can often be handled via punycode/DNS.	Support forum advice points users to punycode. UI acceptance may vary. (Netlify Support Forums)
Vercel	Major web hosting/platform	Unclear / likely partial	Modern stack, custom domains, HTTPS automation.	I found no clear public IDN support statement. Test Unicode and punycode forms before committing anything important. (Vercel)
WeChat	c. 1.41bn users estimate	Unknown / likely partial	Chinese-market software often handles non-ASCII better than Western validators.	Public English documentation on IDN link rendering is thin. Also platform/browser/app boundaries are heavily mediated. (DemandSage)
QQ	c. 517m mobile MAU latest reported estimate	Unknown / likely partial	Links probably clickable inside app contexts.	Direct IDN display/previews need native-app testing. (DMR)