# Convertidor Punycode Convierte nombres de dominio internacionalizados, como los que llevan ñ o tildes, entre Unicode y su forma ASCII xn-- mientras escribes. Pega un dominio, una URL o una dirección de correo; todo se ejecuta en tu navegador. ## Respuesta corta Punycode (RFC 3492) escribe una etiqueta Unicode usando solo letras, dígitos y guiones, e IDNA le agrega el prefijo `xn--`, así que `español.example` se guarda en el DNS como `xn--espaol-zwa.example`. Después de la conversión, cada etiqueta puede tener como máximo 63 caracteres (RFC 1035). ### Cómo se obtiene La conversión se hace etiqueta por etiqueta. Primero se copian los caracteres ASCII de la etiqueta, seguidos de un guion si había alguno; después, cada carácter que no es ASCII se codifica como un número en base 36 de longitud variable que indica qué punto de código insertar y dónde, con las constantes fijadas en el RFC 3492 (base 36, tmin 1, tmax 26, skew 38, damp 700, sesgo inicial 72, n inicial 128). Antes de eso, a la entrada de dominio se le aplica el mapeo IDNA que usan los navegadores (UTS #46): las letras de ancho completo y el punto ideográfico pasan a sus formas ASCII y el nombre se pasa a minúsculas. ### Ejemplo práctico `español`: se copia `espaol`, se agrega `-` y después la ñ (U+00F1), insertada en la posición 4, se codifica como `zwa`, lo que da `espaol-zwa`; así, `español.example` se convierte en `xn--espaol-zwa.example`. En sentido contrario, `xn--wgv71a119e.jp` se decodifica como `日本語.jp`. ### Límites - Se comprueban la longitud y los caracteres, pero no todas las reglas de IDNA2008 (por ejemplo, las reglas de contexto para los caracteres de unión); además, cada registro tiene su propia lista de caracteres permitidos. - Los nombres que mezclan alfabetos se marcan como posibles imitaciones; una imitación escrita en un solo alfabeto, como una palabra latina imitada solo con letras cirílicas, no se detecta. ### Fuentes - [RFC 3492: Punycode](https://www.rfc-editor.org/rfc/rfc3492): el algoritmo y sus constantes. - [RFC 5890: IDNA Definitions](https://www.rfc-editor.org/rfc/rfc5890): el prefijo xn-- y las etiquetas A (A-labels). - [RFC 5891: IDNA Protocol](https://www.rfc-editor.org/rfc/rfc5891): cómo se convierten los nombres para el DNS. - [Unicode UTS #46: IDNA Compatibility Processing](https://www.unicode.org/reports/tr46/): el mapeo que aplican los navegadores. - [RFC 1035, section 2.3.4: Size limits](https://www.rfc-editor.org/rfc/rfc1035#section-2.3.4): 63 octetos por etiqueta. ## Qué hace Este convertidor traduce nombres de dominio internacionalizados (IDN) entre la forma que lee la gente y la forma que guarda el DNS. Escribe `español.example` y obtienes `xn--espaol-zwa.example`; pega un nombre `xn--` y obtienes el original en Unicode. Funciona en los dos sentidos mientras escribes, etiqueta por etiqueta, así que en `tienda.español.example` solo la etiqueta con caracteres que no son ASCII recibe el prefijo `xn--`. La codificación es Punycode (RFC 3492), implementada en JavaScript dentro de tu navegador; nada de lo que escribes se envía a ningún lado. Antes de codificar, la herramienta pasa cada etiqueta a minúsculas y aplica la normalización Unicode NFC, así que una ñ precompuesta y una n seguida de una tilde combinable dan el mismo resultado. No aplica todas las reglas de mapeo de IDNA2008 ni de UTS #46, así que una conversión exitosa es una codificación correcta, no una prueba de que un registro vaya a aceptar el nombre. Junto al resultado ves un desglose de cada etiqueta (forma Unicode, forma ASCII y longitud), una comprobación de los límites del DNS de 63 octetos por etiqueta y 253 para el nombre completo, y un aviso cuando una misma etiqueta mezcla alfabetos, como el latino con el cirílico o el griego. ## Cómo usarlo 1. Escribe o pega un nombre de dominio, una URL completa o una dirección de correo. 2. Mira cómo se actualiza la forma convertida: una entrada en Unicode da la forma `xn--`, y una entrada `xn--` da Unicode. 3. Revisa el desglose de etiquetas para ver las longitudes, los errores de límite y cualquier aviso de alfabetos mezclados. 4. Copia la forma que espera el destino. Con una URL, solo se convierte el host; el resto queda como lo escribiste. (En la web, los caracteres que no son ASCII en una ruta o en una cadena de consulta se codifican con porcentajes como UTF-8; no se convierten a Punycode.) Con una dirección de correo, solo se convierte la parte después de la @. Una parte local como `josé` no tiene forma Punycode; para entregarle correo hace falta que todos los servidores del camino admitan SMTPUTF8 (RFC 6531). ## Casos de uso - **Revisar un enlace sospechoso.** Pega la URL de un mensaje antes de abrirla. Si el host se decodifica en letras de dos alfabetos, o un nombre que parece conocido resulta ser una etiqueta `xn--`, míralo con más cuidado antes de hacer clic. - **Escribir registros DNS.** Los archivos de zona y la mayoría de los paneles de hosting DNS esperan la forma ASCII. Usa exactamente esa cadena en cualquier registro que haga referencia al nombre, incluidos los destinos de CNAME y los hosts de MX. - **Pedir certificados TLS.** Las autoridades de certificación y los clientes ACME usan la forma `xn--` en los nombres alternativos del sujeto (SAN). Decodificar la lista SAN de un certificado muestra qué nombres Unicode cubre en realidad. - **Leer logs.** Los logs de servidores web, los encabezados Host de HTTP y los valores SNI de TLS llevan el nombre codificado. Decodifica una entrada desconocida para leerla. - **Configurar el correo de un IDN.** Los registros MX, SPF, DKIM y DMARC van todos bajo el nombre `xn--`, y una dirección como `info@xn--espaol-zwa.example` funciona con cualquier programa de correo común. - **Comprobar la longitud antes de registrar.** La codificación alarga bastante algunos alfabetos: la etiqueta tailandesa de siete caracteres ภาษาไทย se convierte en `xn--o3crh0a8bb0k`, de 16 octetos, así que una etiqueta que parece corta igual puede pasar de 63. Los registros DNS y una solicitud de firma de certificado (CSR) para `español.example` usan el nombre codificado, como cualquier otro nombre de host: ``` xn--espaol-zwa.example. 3600 IN A 192.0.2.10 www.xn--espaol-zwa.example. 3600 IN CNAME xn--espaol-zwa.example. xn--espaol-zwa.example. 3600 IN MX 10 mail.xn--espaol-zwa.example. openssl req -new -key site.key -out site.csr \ -subj "/CN=xn--espaol-zwa.example" \ -addext "subjectAltName=DNS:xn--espaol-zwa.example,DNS:www.xn--espaol-zwa.example" ``` ## Cómo hace Punycode para meter Unicode en un nombre de host En sentido estricto, el formato del DNS en la red puede llevar cualquier valor de byte. En la práctica, desde los años ochenta los nombres de host se limitan a letras ASCII, dígitos y guion (la regla LDH de los RFC 952 y RFC 1123), y los resolvedores, los servidores de correo y las comprobaciones de certificados se construyeron sobre esa base. En lugar de cambiarlos, IDNA convierte los nombres dentro de la aplicación, antes de enviar cualquier consulta, en una cadena que ya cumple la regla antigua. Punycode trabaja en dos etapas. Primero copia en orden los caracteres ASCII de la etiqueta y agrega un guion si había alguno: `español` da `espaol-`. Después describe cada carácter que falta con un único número que dice qué punto de código insertar y dónde. La ñ es U+00F1, 241 en decimal. Contando desde 128, con seis letras ya colocadas y, por lo tanto, siete posiciones posibles de inserción, el número es (241 − 128) × 7 + 4 = 795, donde el 4 final significa después de la cuarta letra. Ese número se escribe en una forma de base 36 de longitud variable con a–z y 0–9, con umbrales que se adaptan para que los números pequeños queden cortos. El resultado es `zwa`, lo que da `xn--espaol-zwa`. Decodificar invierte el proceso: todo lo que está antes del último guion se copia, y los caracteres que vienen después se leen como inserciones. Una etiqueta sin letras ASCII, como la tailandesa de arriba, no tiene guion separador después del prefijo. Como la etiqueta codificada es la que viaja por el DNS, el límite de 63 octetos se aplica a ella, no al texto Unicode. ## Dominios de imitación y la barra de direcciones Muchas letras de distintos alfabetos se ven idénticas. La а cirílica (U+0430) es igual a la a latina en la mayoría de las fuentes, así que `bаnco.example`, con la segunda letra en cirílico, se lee como una palabra común, pero se codifica como `xn--bnco-53d.example`. Esto es un ataque homográfico. Los navegadores deciden etiqueta por etiqueta si muestran Unicode o la forma `xn--`. Las políticas cambian según el fabricante, pero entre las pruebas habituales están si una etiqueta mezcla alfabetos en combinaciones que los nombres reales casi no usan, si está escrita entera con letras que imitan las latinas y si se parece mucho a un dominio conocido. En Firefox, poner `network.IDN_show_punycode` en true en `about:config` obliga a mostrar la forma ASCII de todos los nombres. El aviso de alfabetos mezclados de esta página busca más de un alfabeto dentro de una misma etiqueta. Una etiqueta escrita toda con letras cirílicas parecidas a las latinas no está mezclada, así que un resultado limpio no prueba que un nombre sea legítimo. Compara el nombre decodificado con la dirección que esperabas y, si tienes dudas, escribe la dirección tú mismo. ## Preguntas frecuentes **¿Cómo se escribe en Punycode un dominio con ñ?** Pega el nombre en el campo de arriba y verás su forma xn-- al instante: por ejemplo, español.example se convierte en xn--espaol-zwa.example. Primero se copian las letras ASCII de la etiqueta, después va un guion y al final un código corto que indica qué carácter insertar y en qué posición, en este caso la ñ después de la cuarta letra. **¿Por qué mi navegador muestra xn-- en lugar del nombre real?** Los navegadores muestran Unicode solo cuando una etiqueta cumple su política de visualización. Si mezcla alfabetos de formas poco habituales, está escrita entera con caracteres que imitan letras latinas o se parece demasiado a un dominio conocido, el navegador muestra la forma codificada. El sitio carga igual que siempre; pega el nombre aquí para ver qué dice la etiqueta xn-- una vez decodificada. **¿Es peligroso un dominio que empieza con xn--?** No. El prefijo solo significa que la etiqueta se codificó a partir de Unicode, y muchos sitios legítimos en alemán, chino, árabe, ruso y otros idiomas lo usan. Lo que importa es el texto decodificado. Si dice el nombre que esperabas, en un solo alfabeto, no tiene nada de raro. Si imita un nombre conocido con letras prestadas de otro alfabeto, trata el enlace con precaución. **¿Por qué otro convertidor da un resultado distinto con la ß alemana?** El procesamiento IDNA2003, más antiguo, y el modo de transición de UTS #46 convierten la ß en ss y la sigma final ς en σ antes de codificar, así que straße queda como strasse a secas. IDNA2008 conserva esos caracteres tal como están. Pasar a minúsculas y aplicar NFC, que son los pasos que hace esta herramienta, deja la ß sin cambios, así que aquí faß se codifica como xn--fa-hia. Comprueba qué forma esperan tu registro y el software de tus usuarios. **¿Puedo poner Unicode directamente en un archivo de zona o en un certificado?** Usa la forma xn-- en los dos. Un certificado guarda los nombres DNS en un campo que solo admite ASCII, así que las autoridades de certificación esperan la forma codificada en la lista de nombres alternativos del sujeto (SAN). En un archivo de zona, un nombre escrito con bytes UTF-8 tal cual no coincidiría con las consultas xn-- que envían los resolvedores y los navegadores, así que el registro nunca se encontraría. **¿Qué pasa con la parte antes de la @ en un correo electrónico?** Queda exactamente como la escribiste, porque Punycode solo se aplica a nombres de dominio. Si la parte local tiene caracteres que no son ASCII, como josé, la entrega depende de la extensión SMTPUTF8 definida en el RFC 6531. Todos los servidores del camino tienen que admitirla; no hay una alternativa ASCII comparable a Punycode, así que un mensaje a esa dirección normalmente rebota donde falta el soporte. **¿Por qué un registro podría rechazar un nombre que esta herramienta convierte sin problemas?** La herramienta hace una codificación correcta según el RFC 3492 después de pasar a minúsculas y normalizar con NFC, pero no implementa todas las reglas de IDNA2008 ni de UTS #46. IDNA2008 prohíbe la mayoría de los símbolos y tiene reglas de contexto para caracteres como los de unión (joiners), y cada registro publica su propia tabla de caracteres permitidos para su dominio de nivel superior. Un nombre puede codificarse bien aquí y aun así no pasar esas comprobaciones. **¿Lo que escribo se envía a algún servidor?** No. La conversión, la comprobación de longitud y el aviso de alfabetos mezclados se ejecutan en JavaScript dentro de tu navegador, así que los nombres, las URL y las direcciones de correo que pegas nunca salen de tu dispositivo. Además, iseeu.cc no guarda registros de direcciones IP ni de consultas, no tiene base de datos de visitantes, no usa cookies y no muestra anuncios. Una conversión limpia muestra que el nombre está bien codificado, no que se pueda registrar ni que sea seguro. Los registros aplican sus propias reglas de caracteres, y los nombres de imitación pueden evitar mezclar alfabetos. ## Herramientas relacionadas - [Consulta DNS](https://iseeu.cc/es/consulta-dns/): Registros A, AAAA, MX, TXT, NS, CNAME, CAA y SOA mediante DNS sobre HTTPS. - [Consulta Whois / RDAP](https://iseeu.cc/es/whois/): Datos de registro de dominios, direcciones IP y números de sistema autónomo. - [Analizador de encabezados de correo](https://iseeu.cc/es/analizador-encabezados-correo/): Sigue la cadena Received y lee los resultados de SPF, DKIM y DMARC. - [Encabezados de seguridad](https://iseeu.cc/es/encabezados-seguridad/): Obtiene los encabezados de respuesta de una URL y califica HSTS, CSP y los demás. - [¿Cuál es mi IP?](https://iseeu.cc/es/): Tu dirección IP, ubicación, red, encabezados, TLS y pruebas de fugas en una sola página. [Ver todas las herramientas](https://iseeu.cc/es/herramientas/) Última actualización: 2026-10-11 Página original: https://iseeu.cc/es/convertidor-punycode/