Skip to content

Generador de slug

Última verificación mayo 2026 — corre en tu navegador

Slug

tu-slug-aqui

Generador de slug URL — Crear slugs amigables para SEO

Escribe un título de blog, nombre de producto, encabezado de página o etiqueta de categoría y la página renderiza la versión URL-safe del slug en vivo debajo. "Café Móvil — 5 Tips y Trucos!" se vuelve `cafe-movil-5-tips-y-trucos`, listo para meter en un CMS, fichero de rutas o nombre de fichero. La transformación es conservadora — solo letras ASCII, dígitos y guiones sobreviven — así que el slug es seguro de usar en cualquier segmento de URL sin más encoding, y estable entre sistemas operativos y CMSes que manejan rutas Unicode de forma distinta. Útil para artesanar permalinks antes de publicar en WordPress, Ghost, Astro, Hugo o Next.js, generar nombres de fichero desde títulos humanos, nombrar imágenes para SEO o producir cadenas identificadoras desde etiquetas en una importación de BD.

Sobre esta herramienta

La tubería corre cinco pasadas en orden: (1) minúsculas vía `String.prototype.toLowerCase` (reglas de minúsculas latinas conscientes de locale — `İ` se vuelve correctamente `i̇` y luego quita la marca combinante en la siguiente pasada); (2) normalización Unicode NFD, que descompone caracteres acentuados en letra base + diacrítico combinante (`á` → `a` + U+0301 combining acute); (3) strip regex del bloque de diacríticos combinantes (`U+0300-U+036F`), dejando solo las letras base; (4) strip regex de todo lo que no es letra ASCII en minúscula, dígito, espacio o guion — así `é` se vuelve `e`, `ñ` se vuelve `n`, pero `&`, `?`, `.`, em-dashes y emoji se descartan; (5) trim, reemplaza secuencias de espacios por un único guion y luego colapsa secuencias de guiones a un único guion. El resultado es un slug determinista e idempotente — correrlo dos veces produce la misma salida. Casos de uso: artesanar permalinks de WordPress/Ghost/Astro antes de publicar, generar nombres de fichero amigables para SEO en imágenes, derivar identificadores de registros de BD desde nombres introducidos por humanos, normalizar etiquetas desde una folksonomía o producir nombres de fichero seguros para un build de sitio estático.

  • Tubería determinista de cinco pasadas — corre igual cada vez
  • La normalización Unicode NFD maneja acentos en cualquier escritura
  • Quita diacríticos combinantes (U+0300-U+036F) — mantiene letras base
  • Descarta todo excepto a-z, 0-9, espacio, guion — seguro para cualquier URL
  • Colapsa espacios repetidos y guiones repetidos a uno cada uno
  • Quita espacios al principio/final antes de poner guiones
  • Reactivo — el slug actualiza mientras escribes
  • Idempotente — correrlo sobre un slug devuelve el mismo slug
  • Copia con un clic al portapapeles con confirmación
  • Útil para permalinks, nombres de fichero, identificadores BD, normalización de tags, SEO de imágenes

Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).

Preguntas frecuentes

¿Por qué el slug es solo ASCII cuando las URLs modernas técnicamente soportan Unicode?

RFC 3986 (Berners-Lee, Fielding, Masinter; enero 2005, IETF / STD 66) define el conjunto de caracteres no reservados como ALPHA / DIGIT / '-' / '.' / '_' / '~' — cualquier cosa fuera de ese rango debe codificarse con porcentajes (percent-encoding) como octetos UTF-8. Los navegadores y servidores modernos soportan URLs Unicode vía percent-encoding (así 'café' se convierte en '%C3%A9' en la ruta), pero la forma codificada con porcentajes es difícil de leer, difícil de compartir verbalmente, frágil al copiar-pegar entre algunos terminales y clientes de email, y manejada inconsistentemente por CMSes y sistemas de analítica. Los slugs ASCII evitan el problema entero — sobreviven cada frontera de codificación, se renderizan idénticamente en todas partes y se mantienen cortos. Para contenido internacionalizado, los CMSes modernos combinan típicamente un slug ASCII con un campo de título Unicode separado en lugar de codificar el título en la URL misma.

¿Por qué la tubería es idempotente — y por qué importa?

Cada pasada — minúsculas, normalizar NFD, eliminar diacríticos combinantes (U+0300–U+036F), eliminar no-alfanuméricos-ASCII, colapsar espacios y guiones — es ella misma idempotente. NFD normalize sobre texto ya descompuesto no tiene efecto; lowercase sobre ASCII ya en minúsculas no tiene efecto; los regex strips no tienen nada que eliminar en una segunda pasada. Así `slugify(slugify(x)) === slugify(x)` para toda entrada. La idempotencia importa para sistemas que puedan generar el slug de la misma entrada dos veces (CMS guardar → re-renderizar → regenerar slug), canonicalización de URLs (un slug recuperado de la base de datos y re-validado debe producirse a sí mismo), y migraciones (re-ejecutar una pasada de generación de slug sobre datos con slug ya aplicado debe ser seguro).

¿Cómo maneja esto las escrituras no-latinas como chino, japonés o árabe?

La descomposición canónica NFD divide caracteres con un mapeo canónico a base + marcas combinantes — principalmente formas precompuestas letra+diacrítico de latín, griego, cirílico y vietnamita. Los ideogramas CJK y la mayoría de letras árabes son atómicas en Unicode y no tienen descomposición canónica. Las sílabas precompuestas de Hangul coreano (U+AC00–U+D7A3) SÍ se descomponen canónicamente en Jamo (U+1100–U+11FF) según UAX #15 §10.1 — pero esos Jamo son descartados luego por la siguiente pasada — eliminar todo lo que esté fuera de [a-z0-9 -] — así que el resultado práctico es el mismo: '東京', '서울' o 'مرحبا' producen un slug vacío, que muchos CMSes (WordPress, Ghost) recurren a un ID de registro como respaldo. Para slugs internacionalizados de verdad, los transliteradores ICU (transformación Latin-ASCII) o bibliotecas de romanización (Hepburn para japonés, Pinyin para chino, Revised Romanization para coreano) proporcionan renderizaciones fonéticas ASCII — están fuera del alcance de un slug determinista por strip.

¿Cuál es la diferencia entre este generador de slug y el modo kebab-case del conversor de mayúsculas?

El modo kebab-case del conversor de mayúsculas aplica el mismo paso NFD más eliminación de diacríticos combinantes pero mantiene cada carácter alfanumérico en el resultado, y luego une los límites de palabra con guiones — así 'Hello World 2025!' se convierte en 'hello-world-2025!' (mantiene los dígitos y el signo de exclamación final si no hay más filtros). slug-generator adicionalmente elimina todo lo que no sea una letra ASCII minúscula, dígito, espacio o guión — así la misma entrada se convierte en 'hello-world-2025'. El slug es más conservador porque la seguridad de URL es la restricción, mientras que el kebab del conversor de mayúsculas es para identificadores de código donde 2025 es un componente perfectamente válido de un nombre de variable.

¿Cómo maneja esta herramienta la accesibilidad para lectores de pantalla?

La región de salida del slug está marcada con aria-live="polite", el patrón del Criterio de Éxito 4.1.3 de WCAG (Mensajes de Estado, introducido en WCAG 2.1, recomendación del W3C del 5 de junio de 2018; trasladado sin cambios a WCAG 2.2, recomendación del 5 de octubre de 2023). Las regiones live polite encolan anuncios tras cualquier habla en progreso, así que editar el título anuncia el nuevo slug sin interrumpir al usuario a mitad de frase. Los lectores de pantalla (NVDA, JAWS, VoiceOver) consumen la región live automáticamente; el usuario no necesita hacer nada más.

Fuentes (5)
  • Berners-Lee, T., Fielding, R., & Masinter, L. (2005). RFC 3986 / STD 66 — Uniform Resource Identifier (URI): Generic Syntax (unreserved = ALPHA / DIGIT / '-' / '.' / '_' / '~'). Internet Engineering Task Force, January 2005.
  • Whistler, K. (Ed.) (2025). UAX #15: Unicode Normalization Forms (NFC, NFD, NFKC, NFKD). Unicode Standard Annex, Revision 57 (Unicode 17.0.0, 30 July 2025).
  • The Unicode Consortium (2024). The Unicode Standard, Version 16.0 — Combining Diacritical Marks block (U+0300–U+036F). Unicode Consortium, Mountain View, CA.
  • ECMA International (2025). ECMAScript 2025 Language Specification — String.prototype.normalize. ECMA-262, 16th edition, June 2025.
  • World Wide Web Consortium (W3C) (2018). Web Content Accessibility Guidelines (WCAG) 2.1 — Success Criterion 4.1.3 Status Messages. W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2 (Recommendation 5 October 2023).

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 ·

Guías relacionadas