🌐 Conversor Punycode / IDN

Convierte nombres de dominio internacionalizados (p. ej. 日本語.jp) ⇔ Punycode (xn--wgv71a119e.jp). Soporta URL completas — cada etiqueta se convierte automáticamente.

100% Gratis Sin registro Solo navegador 5 idiomas Modo oscuro

🔒 Sobre la privacidad

・Todo el procesamiento ocurre en tu navegador
・Tus datos nunca se envían a ningún servidor

Entrada (dominio o URL)

Salida (Punycode ⇄ Unicode)

📖 Cómo funciona

Si la entrada tiene puntos, cada etiqueta se convierte por separado.
URLs con esquema y ruta: solo se convierte el host.
Las etiquetas que contienen solo ASCII se identifican automáticamente como "decode (xn-- → Unicode)"; las etiquetas que contienen caracteres no ASCII se identifican como "encode (Unicode → xn--)".
Bootstring (RFC 3492) implementado en JS puro.

📖 Dónde se suele tropezar

Convierte nombres de dominio internacionalizados y Punycode en ambos sentidos con el algoritmo Bootstring de RFC 3492. Decide etiqueta por etiqueta, separando por puntos, de modo que puedes pegar una URL entera y solo se convierte el host. Todo se ejecuta en el navegador y nada se transmite. Lo que hace esta herramienta es codificar, y nada mas: no juzga si el dominio se puede registrar ni si es seguro. Las restricciones de caracteres de IDNA2008 y UTS-46, la prohibicion de mezclar alfabetos y las reglas propias de cada registro se aplican en una etapa posterior, aparte de esta conversion.

Caso	Qué ocurre	Qué hacer
Un dominio distinto con aspecto identico (homografo)	Muchos sistemas de escritura contienen caracteres indistinguibles de las letras latinas. `U+0430 CYRILLIC SMALL LETTER A`, por ejemplo, se dibuja igual que la `a` latina en casi todas las tipografias. Un dominio que la use como primera letra se codifica como `xn--pple-43d.com`, y aun asi la barra de direcciones puede mostrarlo con la misma grafia que el autentico. Los navegadores pasan a mostrar el Punycode ante condiciones como mezclar alfabetos dentro de una etiqueta o usar un alfabeto que no coincide con el idioma de la interfaz, pero esos criterios difieren entre navegadores y dependen de la configuracion de idioma. Que en tu pantalla se vea con la grafia normal no garantiza nada.	La forma `xn--` es la unica evidencia de la que dispones. Pega aqui el enlace sospechoso y lee la salida. Si un dominio que parece ASCII puro produce un resultado `xn--`, contiene caracteres no latinos. El sentido inverso tambien sirve: pega la forma `xn--` y podras leer la cadena real. Si defiendes a una organizacion, filtra por medios mecanicos y no visuales: marca en la pasarela de correo o en el chat las URL que contengan `xn--`, y manten una lista de dominios permitidos para el trabajo real. La inspeccion humana es franqueable por diseno, asi que la formacion por si sola no es una defensa.
Que se convierta no significa que se pueda registrar ni alcanzar	La codificacion es una operacion mecanica, de modo que cualquier cadena se convierte con exito. El DNS, en cambio, impone sus propios limites. El techo de 63 caracteres por etiqueta se aplica a la forma ya codificada, y los cuatro caracteres de `xn--` cuentan. Como los caracteres kana y han se expanden a entre 1,2 y 1,5 caracteres cada uno, el techo practico en japones ronda los 15 a 20 caracteres. Ademas, los dominios con emoji que pasaban bajo IDNA2003 estan prohibidos bajo IDNA2008 y solo unos pocos TLD los siguen aceptando. En rigor, las mayusculas y los caracteres de ancho completo se normalizan con UTS-46 antes de codificar, pero esta herramienta codifica exactamente lo que escribes: una `Ａ` de ancho completo no se convierte en `a`, se codifica como caracter no ASCII.	El DNS solo ve la forma `xn--`. Para comprobar la accesibilidad, pasa el resultado de la conversion directamente a `dig xn--wgv71a119e.jp` o `whois xn--...`. Cuando una consulta en forma Unicode falla, no puedes distinguir si el dominio no esta registrado o si la herramienta no sabe manejar IDN. Con la longitud pasa lo mismo: lo que hay que contar es la longitud despues de convertir; si la salida supera los 63 caracteres, ningun registrador del mundo podra registrar ese dominio. Antes de comprarlo, consulta la politica IDN del registro (su tabla de caracteres permitidos) en lugar del buscador de un registrador, porque el conjunto de caracteres permitidos cambia segun el TLD.
Las dos formas se separan en correo, certificados y registros	Para el DNS, la forma Unicode y la forma `xn--` son el mismo dominio, pero para cualquier mecanismo que compare cadenas son dos valores distintos. Un certificado TLS lleva la forma `xn--` en sus entradas SAN, de modo que cotejarlo contra la cadena Unicode falla. Los registros de acceso, la analitica y Search Console difieren en cual de las dos formas guardan, y el mismo sitio se parte en dos filas. El correo es aun peor: la parte de dominio puede ir en `xn--`, pero para que la parte local (a la izquierda de la @) sea no ASCII hace falta SMTPUTF8 (RFC 6531), y los MTA sin soporte siguen sin ser raros.	Guarda y compara unicamente la forma `xn--`, y restaura la forma Unicode solo para mostrarla: aplicar eso en un unico punto es la unica respuesta real. Normaliza a `xn--` justo antes de escribir en la base de datos, justo antes de escribir una linea de registro y justo antes de entregar el valor a una API externa. Normalizar solo en un lado es el peor desenlace: las redirecciones y los enlaces entran en bucle y un mismo usuario aparece como dos. En Search Console lo fiable es dar de alta ambas propiedades y sumar las cifras. Si aceptas direcciones de correo, decidir que las partes locales no ASCII no estan soportadas por ahora y decirlo en el formulario es mas amable que aceptarlas a medias y fallar al enviar.

Punycode no es cifrado ni ofuscacion. Bootstring es una codificacion reversible sin clave ni aleatoriedad: cualquiera la deshace en un segundo. Todo diseno que suponga que xn-- vuelve algo ilegible acabara fallando. Trabajar etiqueta por etiqueta tiene una segunda consecuencia: el atacante tambien puede aprovecharla. En el patron example.com.xn--.... se coloca un dominio real a la izquierda, como subdominio, y el xn-- aparece solo en la etiqueta mas a la derecha. Quien posee un dominio lo decide siempre la etiqueta mas a la derecha, la contigua al TLD, y lo que haya a su izquierda es irrelevante. Cuando juzgues un nombre de host, leelo de derecha a izquierda.

📖 Cómo usar

1

Pega un dominio

Pega un dominio internacionalizado o Punycode. Las URL completas también funcionan.
2

Ver el resultado

Si tiene no-ASCII se codifica a xn--; si es ASCII se decodifica.
3

Copia y usa

Pulsa Copiar. Útil para WHOIS, DNS y servidores de correo.

❓ Preguntas frecuentes

¿Qué es Punycode?

Una codificación DNS (RFC 3492) que representa Unicode con solo ASCII.

¿Funciona con emoji?

Técnicamente sí, pero la mayoría de TLD no aceptan emoji.

¿En qué difiere de URL.host?

Las implementaciones varían. Esta herramienta sigue estrictamente RFC 3492.

🔗 Herramientas relacionadas

🐛 ¿Encontró un problema con esta herramienta?

Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.