Haz clic en cualquier carácter para copiarlo al portapapeles.
Caracteres invisibles en 2026 — qué son y dónde fallan
Los caracteres invisibles son puntos de código Unicode que ocupan posición lógica en una cadena pero no producen un glifo visible. Los siete listados arriba pertenecen a la clase de controles de presentación del Capítulo 23 del Estándar Unicode. Tres de ellos — Espacio de Ancho Cero (U+200B), No-Unión de Ancho Cero (U+200C) y Unión de Ancho Cero (U+200D) — existen por razones tipográficas legítimas: U+200B marca límites de palabra en tailandés, jemer, birmano y lao según UAX #14 y UAX #29; U+200C y U+200D controlan ligaduras en árabe, persa, devanagari y secuencias ZWJ de emoji (el emoji de familia 👨👩👧 son cinco puntos de código: U+1F468 + U+200D + U+1F469 + U+200D + U+1F467). El abuso aparece cuando estos caracteres viajan por identificadores, URLs o prompts a un LLM. El estudio de tráfico DNS de Akamai (2022) detectó 6.670 dominios IDN homógrafos en 29.071 dispositivos durante 32 días, explotando confusables visuales catalogados en MITRE CWE-1007. Desde IDNA2008, las defensas convergen en normalización Punycode (RFC 3492) en la capa del registrador y enforcement PRECIS IdentifierClass (RFC 7564) en la capa de protocolo; las ICANN IDN Implementation Guidelines v4.1 (noviembre 2022) fijan la línea base de los registros. El comportamiento por plataforma diverge. Twitter filtra U+200B de cuerpos de tweet y nombres visibles según informes de terceros hasta 2026. Discord acepta U+3164 (Hangul Filler) de forma consistente porque su General Category es Lo (Letra, otro) y no Cf (Formato). Mastodon aplica RFC 7564 a handles remotos y reglas ASCII más estrictas en local — los invisibles se rechazan en ambas barreras. Los asistentes de IA se volvieron superficie de ataque en 2025: la inyección de prompts oculta vía caracteres del bloque Tag (U+E0000–U+E007F) se demostró contra Amazon Q Developer ese año; AWS Bedrock Guardrails añadió un filtro de prompt-attack ese año, pero AWS WAF no ofrece una regla gestionada específica para invisibles — la práctica habitual es desplegar reglas byte-match propias. El coste en bytes importa: U+200B se codifica a 3 bytes en UTF-8 (RFC 3629 §3) frente a 1 byte del espacio ASCII, así que un tweet de 280 caracteres rellenado con espacios de ancho cero ocupa el triple de payload de lo que aparenta. La colección de esta página permite copiar cada carácter para inspeccionar cómo lo normaliza, muestra o rechaza un sistema concreto.
Cómo encaja esta herramienta con el resto
Combínala con el Contador de caracteres para comparar longitud visible vs total, con el generador de Lorem Ipsum cuando los fixtures de test necesitan relleno que no interfiera con las variables bajo prueba, y con el conversor de Texto a Binario para inspeccionar cómo se codifica cada carácter en bytes UTF-8.
- 7 caracteres de control de presentación (U+200B, U+200C, U+200D, U+2060, U+00AD, U+200A, U+2800)
- Punto de código Unicode y descripción breve por carácter
- Copia con un clic — el carácter va al portapapeles sin transformación
- Corre en el navegador; copiar no hace ninguna petición de red
Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).
Preguntas frecuentes
¿Por qué X (Twitter, Discord, Mastodon…) me quita el espacio de ancho cero que acabo de pegar?
Cada plataforma aplica su propia normalización. Twitter filtra U+200B de cuerpos de tweet y nombres visibles según reportes de terceros. Discord acepta U+3164 (Hangul Filler) porque su General Category Unicode es Lo (Letra, otro) y no Cf (Formato), de modo que los validadores que bloquean caracteres de formato lo dejan pasar. Mastodon aplica RFC 7564 PRECIS IdentifierClass a los handles remotos y reglas ASCII más estrictas al registro local — los invisibles fallan en ambas barreras. Las diferencias son intencionadas: cada superficie decide cuánto quiere apretar.
¿Por qué U+200B son 3 bytes cuando un espacio ASCII es 1?
UTF-8 codifica los puntos de código del rango U+0800–U+FFFF con tres bytes (RFC 3629 §3). U+200B cae en ese rango. El espacio ASCII (U+0020) está en U+0000–U+007F y se codifica con un único byte. El ancho visual es cero en ambos, pero el coste en cable y disco se multiplica por 3. Un tweet rellenado a 280 caracteres con U+200B carga el mismo payload que unos 840 caracteres ASCII, lo cual importa para gateways SMS, rotación de logs y cualquier sistema que facture o presupueste por byte en lugar de por glifo visible.
¿Son legítimos los caracteres de ancho cero o solo sirven para trucos?
Ambas cosas. U+200B marca límites de palabra en tailandés, jemer, birmano y lao — escrituras que no separan las palabras con espacios — y el Unicode Standard Annex #14 lo trata como oportunidad de salto de línea suave. U+200C y U+200D controlan ligaduras en árabe, persa y devanagari, y las secuencias ZWJ de emoji (el emoji de familia 👨👩👧 son cinco puntos de código: U+1F468 + U+200D + U+1F469 + U+200D + U+1F467). El abuso y el uso legítimo comparten los mismos puntos de código; la postura de seguridad vive en la normalización, no en prohibir el carácter.
¿Sirven estos caracteres para atacar asistentes de IA o sitios web?
La inyección de prompts oculta mediante caracteres del bloque Tag (U+E0000–U+E007F) se demostró contra Amazon Q Developer en 2025. AWS Bedrock Guardrails añadió un filtro de prompt-attack ese año, aunque AWS WAF no incluye una regla gestionada específica para inyección con invisibles — la práctica habitual es desplegar reglas byte-match propias. En la web, los dominios IDN homógrafos abusan de caracteres visualmente confundibles; el estudio de tráfico DNS de Akamai (2022) detectó 6.670 dominios de este tipo en 29.071 dispositivos durante 32 días. MITRE cataloga la debilidad subyacente como CWE-1007.
¿Cómo se defienden los registradores y protocolos frente al abuso de invisibles?
En la capa DNS, IDNA normaliza las etiquetas Unicode a Punycode (RFC 3492 / IDNA2008 RFC 5891–5892); las ICANN IDN Implementation Guidelines v4.1 (noviembre 2022) fijan la línea base de los registros. En la capa de protocolo, RFC 7564 (Marco PRECIS) define la IdentifierClass que las aplicaciones estrictas usan para rechazar caracteres de formato en nombres de usuario y de recurso. UTS #39 (Unicode Security Mechanisms) define el algoritmo de detección de confusables que registradores y sistemas de identidad emplean cuando la política exige comparar cadenas por similitud visual.
Fuentes (9)
- The Unicode Consortium (2024). The Unicode Standard, Version 16.0 — Chapter 23 (Special Areas and Format Characters). Unicode Consortium, Mountain View, CA.
- Davis, M., & Suignard, M. (Eds.) (2024). UAX #14: Unicode Line Breaking Algorithm. Unicode Standard Annex, revision 53 (Unicode 16.0).
- Davis, M. (2024). UTS #39: Unicode Security Mechanisms. Unicode Technical Standard, version 16.0.0.
- Yergeau, F. (2003). UTF-8, a transformation format of ISO 10646. RFC 3629, IETF.
- Costello, A. (2003). Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). RFC 3492, IETF.
- Klensin, J. (2010). Internationalized Domain Names in Applications (IDNA): Protocol. RFC 5891, IETF (IDNA2008).
- Saint-Andre, P., & Blanchet, M. (2015). PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols. RFC 7564, IETF.
- MITRE Corporation (2024). CWE-1007: Insufficient Visual Distinction of Homoglyphs Presented to User. Common Weakness Enumeration v4.19.1 (introduced CWE 3.1, 2018).
- ICANN (2022). IDN Implementation Guidelines v4.1. Internet Corporation for Assigned Names and Numbers (17 November 2022).
Son las publicaciones originales en las que se basan las fórmulas de esta herramienta. Localízalas con el nombre de la revista y el año en Google Scholar o PubMed.
Por Marco B. ·