Límites de caracteres y palabras 2026 — Twitter, SMS, SEO, Instagram

Un límite de caracteres es la cantidad máxima de puntos de código (codepoints) Unicode que una plataforma acepta en un solo campo: 280 para una publicación de Twitter, 160 para un SMS de un solo segmento en GSM-7, alrededor de 160 para una meta description de Google antes de que se trunque. El número que les sirve depende de dónde publican y de si el texto contiene emoji, comillas tipográficas o caracteres CJK, ya que todos cambian la matemática.

Esta guía está pensada para redactores de redes sociales, gente de SEO, copywriters de marketing, remitentes de SMS facturados por segmento y desarrolladores que escriben validaciones que deben coincidir con lo que Twitter, Instagram o las pasarelas SMS realmente cuentan. Si quieren la hoja de trucos de 25 plataformas, vayan a la tabla de referencia rápida; para verificar un borrador en vivo contra seis plataformas principales, usen el Contador de Palabras. Las barras de progreso se ponen rojas en cuanto cruzan un límite.

Referencia rápida — Límite de caracteres y palabras de cada plataforma

La tabla siguiente cubre los más de 30 campos con los que se topan a diario redactores y desarrolladores. “Límite duro” es el tope que impone la plataforma. “Visible / arriba del pliegue” es lo que ven los lectores antes del punto de truncamiento. “Punto óptimo” es el rango empírico donde el contenido rinde mejor.

Plataforma	Límite duro	Visible / arriba del pliegue	Punto óptimo	Cuenta emoji como
Publicación de Twitter / X	280 caracteres	280	70-100 caracteres	1 codepoint
Bio de Twitter / X	160 caracteres	160	—	1 codepoint
Nombre visible de Twitter / X	50 caracteres	50	—	1 codepoint
X Premium formato largo	25,000 caracteres	—	—	1 codepoint
Pie de foto de Instagram	2,200 caracteres	primeros 125 (luego “más”)	<125 para el gancho	1 codepoint
Bio de Instagram	150 caracteres	150	—	1 codepoint
Hashtags de Instagram	máx. 30	—	5-10	—
Publicación de LinkedIn	3,000 caracteres	primeros 210 (luego “ver más”)	<1,300	1 codepoint
Artículo de LinkedIn	110,000 caracteres	—	—	1 codepoint
Titular de LinkedIn	220 caracteres	220	—	1 codepoint
Publicación de Facebook	63,206 caracteres	~477 escritorio / ~125 móvil	<80 para orgánico	1 codepoint
Pie de TikTok	2,200 caracteres	primeros ~100	<150	1 codepoint
Título de YouTube	100 caracteres	70 (búsqueda)	<60	1 codepoint
Descripción de YouTube	5,000 caracteres	primeros 100-150 arriba del pliegue	primeros 150 como gancho	1 codepoint
Comentario de YouTube	10,000 caracteres	—	—	1 codepoint
Título de Reddit	300 caracteres	—	<60 (depende del subreddit)	1 codepoint
Comentario de Reddit	10,000 caracteres	—	—	1 codepoint
Mensaje de Discord	2,000 caracteres	2,000	—	1 codepoint
Descripción de embed en Discord	4,096 caracteres	—	—	1 codepoint
Mensaje de Slack	40,000 caracteres	—	<2,000 por legibilidad	1 codepoint
Descripción de pin en Pinterest	500 caracteres	primeros 50-60	<125	1 codepoint
Toot de Mastodon	500 caracteres (configurable)	500	—	1 codepoint
Publicación de Bluesky	300 caracteres	300	—	1 grapheme cluster
Publicación de Threads	500 caracteres	500	—	1 codepoint
Meta description SEO (Google)	~160 caracteres escritorio / ~120 móvil	150-160	150-160	1 codepoint
Title tag SEO (Google)	~60 caracteres escritorio / ~50 móvil	50-60	50-60	1 codepoint
Descripción Open Graph	~200 caracteres antes del corte de LinkedIn/FB	150-200	150-200	1 codepoint
Descripción de Twitter Card	200 caracteres máx.	200	150-200	1 codepoint
SMS un solo segmento (GSM-7)	160 caracteres	—	—	especial — ver abajo
SMS un solo segmento (UCS-2 / emoji)	70 caracteres	—	—	1 codepoint
Texto de mensaje de WhatsApp	65,536 caracteres	—	—	1 codepoint
Asunto de email	sin límite de plataforma	~60 escritorio / ~30 móvil	<50	1 codepoint
Titular de Google Ads	30 caracteres × 15 titulares	30 cada uno	30	1 codepoint
Descripción de Google Ads	90 caracteres × 4 descripciones	90 cada una	90	1 codepoint
Título de App Store	30 caracteres	30	30	1 codepoint
Subtítulo de App Store	30 caracteres	30	30	1 codepoint
Descripción de App Store	4,000 caracteres	primeros 252 arriba del pliegue	gancho de 252	1 codepoint
Descripción corta de Play Store	80 caracteres	80	80	1 codepoint
Descripción larga de Play Store	4,000 caracteres	primeros 80 arriba del pliegue	gancho de 80	1 codepoint

El contenido que pasa la línea del “punto óptimo” tiende a truncarse, perder posicionamiento o quedar cortado fuera de la tarjeta visible. X Premium formato largo y Mastodon (configurable por instancia) son las pocas excepciones que permiten escribir más allá de 500 caracteres sin penalización. Cada conteo de la tabla, salvo donde aplican las reglas de SMS, es un conteo de puntos de código Unicode: un emoji cuesta 1 carácter, no 2. Para verificar un borrador contra los seis límites más comunes a la vez, péguenlo en el Contador de Palabras; las barras de progreso atrapan el texto excedido antes de que lo publiquen.

Cómo se cuentan realmente los caracteres (puntos de código Unicode vs UTF-16)

Tres herramientas distintas pueden devolverles tres conteos distintos de caracteres para la misma cadena. La razón es que “carácter” no es una sola cosa: puede significar un punto de código Unicode, una unidad de código UTF-16 o un grapheme cluster, y cada plataforma elige uno.

Qué es un “carácter” — codepoint vs code unit vs grapheme

Un codepoint (punto de código) es un valor escalar Unicode: cualquier entero de U+0000 a U+10FFFF que Unicode haya asignado a un carácter o marcado como reservado. Una code unit (unidad de código) es la pieza más pequeña de una codificación; UTF-16 usa unidades de código de 16 bits, UTF-8 usa unidades de 8 bits. Un grapheme cluster (grupo de grafemas) es lo que las personas perciben como un solo carácter visible: a veces es un codepoint, a veces un codepoint base más marcas combinantes, a veces una secuencia con zero-width-joiner como el emoji de familia 👨‍👩‍👧‍👦 (siete codepoints unidos en un único glifo visible).

Para la cadena "a🌍👨‍👩‍👧" los tres conteos no coinciden:

Método de conteo	Resultado	Usado por
Unidades de código UTF-16 (`string.length` de JS)	10	Código JavaScript ingenuo
Puntos de código Unicode	6	Twitter, Instagram, pasarelas SMS
Grapheme clusters	3	Bluesky, lectores de pantalla, editores de texto

Por qué `string.length` miente con los emoji

JavaScript almacena las cadenas internamente como UTF-16. Cualquier codepoint por encima de U+FFFF (todos los emoji, todos los caracteres del plano astral) se codifica como un par sustituto (surrogate pair): dos unidades de código de 16 bits. La propiedad .length reporta esas dos unidades, no un carácter.

"🌍".length              // 2   (UTF-16 code units)
[..."🌍"].length         // 1   (codepoints — what Twitter/SMS counts)
"🌍".match(/./gu).length // 1   (codepoints via regex with /u flag)

El operador de propagación y el flag /u de regex iteran ambos por codepoint, que es lo que Twitter, Instagram y las pasarelas SMS miden contra sus límites. Una función de validación que use .length crudo rechazará tuits que en realidad están bajo el tope, o peor, dejará pasar mensajes que su sistema downstream va a rechazar.

Y qué pasa con CJK y las marcas combinantes

Cada ideograma chino, japonés y coreano es un único codepoint y cuenta como un carácter en todas las plataformas. Donde se vuelven costosos es en SMS: cualquier carácter fuera de GSM-7 cambia todo el mensaje a codificación UCS-2, y el límite por segmento cae de 160 a 70. La próxima sección entra en detalle.

Las marcas combinantes se comportan distinto. La á acentuada escrita como á es un codepoint; la misma á escrita como a + ́ (acento agudo combinante) son dos codepoints pero un único grapheme cluster. La mayoría de las plataformas cuentan por codepoint, así que la segunda forma cuesta un carácter extra. Bluesky es la excepción visible: cuenta grapheme clusters, así que ambas formas cuestan 1.

Conteo en distintos lenguajes — referencia rápida

// JavaScript
[...str].length                          // codepoints
Array.from(str).length                   // codepoints

// Python 3 — len() is codepoint by default
len(s)

// Go — utf8 package
utf8.RuneCountInString(s)

// Rust — chars() iterates codepoints
s.chars().count()

// Java — codePointCount
s.codePointCount(0, s.length())

Para contrastar, el codificador Base64 muestra la otra dirección: cuando el texto se codifica a Base64 para transmisión, cada 3 bytes de entrada UTF-8 se convierten en 4 caracteres ASCII de salida, así que la longitud codificada depende del conteo de bytes, no del conteo de codepoints. Peguen un solo emoji y verán cómo la salida Base64 se expande a 8 caracteres: el mismo emoji que cuesta 1 carácter en Twitter ocupa 4 bytes en UTF-8.

Para ver los conteos de codepoint (el número que Twitter realmente mide) en cualquier borrador, el Contador de Palabras es Unicode-correcto por defecto.

Límite de caracteres SMS — GSM-7, UCS-2 y mensajes multi-parte

SMS es el único canal importante donde agregar un solo emoji puede literalmente duplicar la factura. La causa es la codificación, y la matemática no ha cambiado desde 1985.

El número mágico 160 — historia de GSM-7

El estándar GSM-03.38 de 1985 fijó la carga útil de un SMS en 140 bytes. Con una codificación de caracteres de 7 bits, 140 bytes contienen 1,120 bits ÷ 7 = 160 caracteres. De ahí viene el conocido sms character limit de 160. El conjunto de caracteres GSM-7 cubre 128 caracteres base más una extensión de 10 caracteres (que cubre { } [ ] | \ ~ ^ € y form feed). Dentro de ese conjunto disponen del presupuesto completo de 160 caracteres por segmento.

Caracteres que quedan fuera de GSM-7 y fuerzan el cambio:

Todos los emoji
Comillas tipográficas o curvas (" " ' '); ojo, son distintas de las comillas rectas ASCII " '
La mayoría de letras latinas acentuadas más allá de las 35 que están en GSM-7 (é á ñ ü ø etc.; GSM-7 incluye solo ä ö å æ ø à è ì ò ù y unas pocas más)
Puntuación de ancho completo, caracteres CJK, árabe, hebreo, griego minúscula, cirílico
Backtick ` y tilde ~ (la tilde está en la tabla de extensión GSM-7, así que cuesta 2 de sus 160 caracteres)

La trampa UCS-2 — un emoji las baja de 160 a 70

En el momento en que aparece un solo carácter fuera de GSM-7 en cualquier parte del mensaje, todo el mensaje cambia a codificación UCS-2. UCS-2 usa 16 bits por carácter, así que 140 bytes ÷ 2 = 70 caracteres por segmento. Ejemplos reales:

"Hello, your code is 12345"            → 26 chars, GSM-7, 1 segment
"Hello, your code is 12345 ✓"          → 28 chars, GSM-7 (✓ in extension), 1 segment
"Hello, your code is 12345 ✅"          → 28 chars, UCS-2 (emoji), 1 segment (under 70)
"Hello, "your" code is 12345 ✅"        → smart quotes + emoji → UCS-2
"Hi 你好"                                → CJK → UCS-2, 1 segment (5 chars)

Ese último ejemplo “Hi 你好” es donde la gente se equivoca: son solo 5 caracteres pero se les aplica precio UCS-2 y los siguientes 65 caracteres que agreguen entrarán en un segmento, luego empieza el segmento 2.

SMS multi-parte (concatenación)

Una vez que cruzan los 160 (GSM-7) o los 70 (UCS-2), el mensaje se divide en múltiples segmentos. Cada segmento lleva un User Data Header (UDH) de 7 caracteres usado para el reensamblado, así que la carga útil disponible por segmento cae:

GSM-7 multi-parte: 153 caracteres por segmento
UCS-2 multi-parte: 67 caracteres por segmento

El teléfono receptor reensambla los segmentos de forma invisible para el destinatario, pero la facturación es por segmento, no por mensaje. Un mensaje GSM-7 de 161 caracteres cuesta 2 segmentos. Un mensaje GSM-7 de 1,000 caracteres cuesta 7 segmentos (153 × 6 = 918, el 7° segmento lleva los últimos 82).

Matemática de costos — cuando un emoji duplica la factura

Consideren un mensaje de marketing de texto plano de 80 caracteres:

Texto plano: 80 caracteres → GSM-7 → 1 segmento a precio X
Agregar un emoji: 80 caracteres → UCS-2 → 80 > 70 → 2 segmentos a precio 2X

Duplicar la factura por un emoji es real y escala. Una campaña de 100,000 mensajes a $0.0075 por segmento cuesta $750 en GSM-7 vs. $1,500 en UCS-2: un emoji de $750. Todos los proveedores SMS importantes (Twilio, Bandwidth, AWS SNS, MessageBird, Vonage) facturan así. Las reglas de codificación son del estándar GSM, no política del proveedor. La historia profunda de los compromisos de codificación a nivel byte, y por qué ASCII, UTF-8 y UCS-2 existen como estándares separados, está cubierta en Entendiendo Base64, que aplica la misma familia de problemas “bits a caracteres” a email en lugar de SMS.

Cómo mantener los mensajes en GSM-7

Usen comillas rectas ASCII " ', no comillas tipográficas
Usen guion ASCII -, no raya — ni guion corto –
Escriban (c) y (R), no © ni ®
Eviten emoji a menos que el presupuesto de campaña asuma costo UCS-2
Las consolas de los proveedores (Twilio, Bandwidth, MessageBird) muestran “encoding: GSM-7” o “UCS-2” junto al preview; verifiquen antes de enviar

La verificación rápida más útil durante la redacción es la barra de progreso SMS del Contador de Palabras: reporta contra la línea base de 160 caracteres. Si su texto dispara UCS-2, dividan mentalmente el conteo de caracteres entre 2.29 para estimar la cantidad de segmentos bajo la regla de 70 caracteres.

Límites SEO — Meta description, Title tag, OG, Twitter Card

Los límites SEO de caracteres son más blandos que los de plataforma. Google no va a rechazar su página si una meta description llega a 300 caracteres, pero las reglas prácticas de truncamiento importan para la tasa de clics. Estos son los números que siguen vigentes en 2026.

Meta description — punto óptimo de 150-160 caracteres

Los resultados de búsqueda de Google en escritorio truncan la meta description alrededor de los 155-165 caracteres; en móvil se corta entre 100 y 120. El punto exacto de truncamiento varía porque Google mide píxeles de pantalla, no caracteres. Una descripción llena de glifos W y M llega al píxel de truncamiento antes que una llena de i y l.

Reglas prácticas de redacción:

Apunten a 150-160 caracteres en total
Pongan el mensaje principal en los primeros 120 caracteres (seguro para móvil)
Empiecen con la keyword meta description character limit de la página en los primeros 30 caracteres
Terminen con un CTA en los últimos 30 caracteres, que queda legible incluso cuando escritorio recorta el medio

Entre 2017 y 2018 Google expandió brevemente la visualización de la meta description a 320 caracteres, y una generación de tutoriales SEO sigue citando ese número. Google volvió a 160 a mediados de 2018. Escribir más allá de 200 caracteres hoy solo oculta la segunda mitad.

Otro modo de falla: las descripciones de menos de 120 caracteres a menudo se reemplazan por completo. Google decide que su descripción no sirve plenamente a la consulta y toma un pasaje distinto del cuerpo de la página, y pierden control de la CTR sin aviso.

Title tag — 60 escritorio, 50 móvil

Los title tags se cortan aproximadamente a los 60 caracteres en escritorio y a los 50 en móvil. Mismo truncamiento por píxeles que las descripciones, mismo cuidado con los glifos anchos.

Punto óptimo: 50-60 caracteres, con la keyword objetivo en los primeros 30 para que sobreviva a cualquier corte. Los sufijos largos de marca (| Brand Name) van al final, donde el truncamiento duele menos.

Ancho de píxeles vs conteo de caracteres — la regla real de Google

El contenedor de descripción del SERP de Google mide aproximadamente 920 píxeles de ancho en escritorio. El ancho promedio de carácter ronda los 6.5 píxeles, lo que da el objetivo empírico de 140-160 caracteres. Pero la dispersión por carácter es grande: i se renderiza a unos 3 píxeles, M a unos 11. Una descripción toda en mayúsculas (“BEST WIDGETS FOR WINTER WEDDINGS”) se recorta bastante antes que el equivalente en minúsculas.

Las previsualizaciones pre-publicación usando simuladores SERP precisos a nivel píxel son más confiables que los contadores de caracteres para copy SEO.

Descripción OG y descripción de Twitter Card

El og:description del protocolo Open Graph es lo que Facebook, LinkedIn, Slack y Discord muestran bajo la vista previa de un enlace compartido. Los topes de visualización varían por plataforma: la mayoría corta alrededor de 200 caracteres, algunas extienden hasta 300. El twitter:description de Twitter Card tiene un tope duro de 200 caracteres en el parser de Twitter.

Defaults sensatos:

150-200 caracteres para OG y Twitter Card
Pueden coincidir con su meta description, pero OG puede ser un poco más larga porque la longitud OG no afecta el ranking de búsqueda
Validen sus elecciones de structured data (especialmente lo que se filtra a OG por error) usando los patrones de Buenas prácticas de seguridad, donde los metadatos OG no confiables son un vector común de phishing

Qué significa realmente “sin límite de caracteres”

Las etiquetas H1, el contenido del cuerpo y los slugs de URL no tienen un límite de caracteres SEO impuesto por la plataforma, pero igual aplican límites blandos:

H1 > 70 caracteres rompe la jerarquía visual y la facilidad de escaneo
Slugs de URL técnicamente ilimitados; Google muestra alrededor de 90 caracteres en el SERP, el resto es cosmético
El contenido del cuerpo no tiene tope de longitud, pero Google rankea contenido útil sobre relleno; el conteo de palabras por sí solo no es señal de ranking

El Contador de Palabras rastrea en vivo tanto meta description (160) como title tag (60) mientras redactan, con barras de progreso que se ponen ámbar y rojas a medida que se acercan al píxel de truncamiento.

Plataformas sociales — Twitter/X, Instagram, LinkedIn, Facebook y más

El techo de caracteres de cada plataforma tiene una historia detrás y un punto óptimo bajo el límite duro donde el contenido realmente rinde.

Twitter / X — 280, premium 25,000, regla de sustitución de URL

El twitter character limit estándar es 280 caracteres, duplicado desde 140 en noviembre de 2017. Los suscriptores de X Premium pueden publicar contenido de formato largo hasta 25,000 caracteres con formato enriquecido, pero la publicación de 280 caracteres sigue siendo la forma dominante para alcance orgánico.

La regla no obvia es la sustitución de URL. Twitter envuelve toda URL, sin importar lo larga que sea, en un enlace corto t.co de 23 caracteres en el momento de publicar. El costo de 23 caracteres es fijo.

published_length = raw_length − URL_length + 23

Ejemplo: un borrador como "Check this: https://example.com/very-long-path?id=12345" tiene 53 caracteres crudos. La URL tiene 38 caracteres, así que se reemplaza por un enlace t.co de 23 caracteres, y la longitud publicada es 53 − 38 + 23 = 38 caracteres. Se ahorran 15 caracteres que no sabían que tenían.

Para pegar una URL larga en un borrador, el codificador/decodificador URL es una forma rápida de verificar qué cuenta como URL (Twitter reconoce URLs por patrones RFC 3986 — query strings y fragments incluidos). Subdominios, esquemas, puertos, rutas, queries y fragments son todos absorbidos por la sustitución de 23 caracteres.

Otros campos de Twitter: nombre visible 50 caracteres, bio 160 caracteres, handle 15 caracteres. Threads (el equivalente de Twitter de Meta) usa en cambio un límite de 500 caracteres.

Instagram — 2,200 en el pie, 30 hashtags, gancho de 125 caracteres

Los pies de foto de Instagram permiten 2,200 caracteres, pero el feed solo muestra los primeros 125 caracteres antes de colapsar el resto detrás de un toque ”… más”. Más de la mitad de los lectores nunca toca. El instagram caption limit que importa para la interacción es por lo tanto 125, aunque el límite duro sea 2,200.

El tope de 30 hashtags es duro: intentar un hashtag 31 hace fallar la publicación. El rango de 5-10 hashtags tiende a rendir mejor; pasados los 11 el impulso de descubrimiento se aplana y la publicación empieza a parecerle spam al algoritmo.

Otros campos: bio 150 caracteres, nombre visible 30 caracteres, DM 1,000 caracteres.

LinkedIn — 3,000 en la publicación, 1,300 como punto óptimo, pliegue “ver más”

El linkedin character limit para publicaciones es 3,000, pero el feed solo muestra los primeros 210 caracteres antes del pliegue “ver más”. Las publicaciones en el rango de 1,200-1,500 caracteres ganan en interacción en LinkedIn (múltiples estudios de Buffer y Hootsuite convergen en alrededor de 1,300 como pico); son lo bastante largas para demostrar valor y lo bastante cortas para no cansar el scroll.

Los Artículos de LinkedIn (la superficie de publicación de formato largo) permiten 110,000 caracteres, efectivamente ilimitado. Los titulares de perfil se topan en 220, el texto de la sección Acerca de en 2,600.

Facebook — 63,206 caracteres, punto óptimo orgánico de 80

El límite de 63,206 caracteres en publicaciones de Facebook es básicamente trivia; en la práctica las publicaciones bajo 80 caracteres reciben alrededor de 30% más interacción orgánica que las más largas (HubSpot lo reporta consistentemente año tras año). Arriba del pliegue, escritorio muestra unos 477 caracteres; móvil corta en unos 125.

El máximo de comentario son 8,000 caracteres. Reacciones, compartidos y clics se inclinan todos hacia publicaciones más cortas; el copy largo pertenece al artículo enlazado, no al pie de Facebook.

Plataformas nuevas — Bluesky, Mastodon, Threads, TikTok

Bluesky las publicaciones se topan en 300 caracteres y son el caso inusual: Bluesky cuenta grapheme clusters, así que el emoji de familia de siete codepoints 👨‍👩‍👧‍👦 cuesta 1 carácter, no 7
Mastodon por defecto 500 caracteres por toot, pero los administradores de la instancia pueden subirlo a 5,000 o incluso a ilimitado; revisen la instancia desde la que publican
Threads usa límites estilo Twitter de 500 caracteres con conteo por codepoint
TikTok los pies permiten 2,200 caracteres con aproximadamente 100 visibles arriba del pliegue

Reddit, Discord, Slack — formato largo y defaults de comunidad

Reddit título 300 caracteres (los moderadores de subreddit a menudo imponen <60 vía AutoModerator); comentarios 10,000 caracteres
Discord mensaje estándar 2,000 caracteres; descripciones de embed 4,096; Nitro lo sube a 4,000 en mensajes planos
Slack mensaje 40,000 caracteres; pasados los 2,000 la legibilidad cae fuerte y muchos destinatarios ignoran los mensajes largos

Objetivos de conteo de palabras por tipo de contenido

Los límites de caracteres dominan en redes sociales y SEO; los conteos de palabras dominan en todo lo demás: trabajos académicos, facturación, content marketing, manuscritos. La tabla siguiente da un rango objetivo y una estimación de tiempo de lectura (230 ppm, la mediana del meta-análisis de lectura silenciosa de Brysbaert 2019) para cada tipo común de contenido.

Tipo de contenido	Objetivo de palabras	Tiempo de lectura @ 230 ppm	Notas
Tuit	30-40 palabras	10 seg	optimizar por carácter, no por palabra
Publicación LinkedIn (punto óptimo)	170-250 palabras	1 min	arriba del pliegue
Pie de Instagram (gancho)	20-25 palabras	<10 seg	primeros 125 caracteres
Post de blog — corto	500-700 palabras	2-3 min	listicle, noticia, hot take
Post de blog — estándar	1,000-1,500 palabras	4-7 min	tutorial, guía profunda
Post de blog — largo	2,000-3,000 palabras	9-13 min	guía exhaustiva
Página pilar SEO	2,500-5,000 palabras	11-22 min	autoridad temática
Ensayo académico (secundaria)	500-1,500 palabras	2-7 min	varía por asignación
Ensayo académico (universitario)	1,500-3,000 palabras	7-13 min	por asignación
NaNoWriMo diario	1,667 palabras/día	—	50K palabras en 30 días
Novela — corta	50,000-70,000 palabras	—	YA, misterio
Novela — estándar	80,000-100,000 palabras	—	ficción adulta
Charla de conferencia (12 min @ 130 ppm)	1,500-1,600 palabras	habla	ensayar para confirmar
Episodio de podcast (30 min @ 130 ppm)	3,900 palabras	habla	porción guionada

El tiempo de lectura es la unidad objetivo más útil para content marketing: los lectores responden a una etiqueta “5 minutos de lectura” de forma más confiable que a “1,150 palabras”. El conteo de palabras sigue siendo la unidad para facturación (traducción facturada por palabra origen), cumplimiento de plataforma (los 50K de NaNoWriMo, un techo académico de 2,000 palabras) y términos de contrato. El Contador de Palabras muestra ambos en tiempo real mientras escriben, más el tiempo de habla a 130 ppm para charlas y podcasts.

6 errores de conteo que rompen apps reales

Estos son los fallos recurrentes vistos en código en producción y en campañas de marketing en producción. Cada uno viene con el síntoma, la causa raíz y la corrección.

Error 1: Usar `string.length` para validar límites de caracteres

Síntoma: Una persona pega un tuit con tres emoji que en realidad son 270 codepoints. Su validación front-end dice 276 y se niega a enviar. O peor: su código acepta un borrador de 285 codepoints porque el presupuesto de emoji se cancela, y Twitter lo rechaza del lado del servidor.

Causa raíz: String.prototype.length en JavaScript devuelve unidades de código UTF-16. Cada emoji es un par sustituto y cuesta 2 unidades. Cada carácter del plano astral (símbolos matemáticos, escrituras antiguas) hace lo mismo.

Corrección: Iteren por codepoint con el operador de propagación o Array.from.

// ❌ wrong
function isUnderTwitterLimit(text) {
  return text.length <= 280;
}

// ✅ correct
function isUnderTwitterLimit(text) {
  return [...text].length <= 280;
}

Para patrones más profundos de iteración por codepoint basados en regex (incluido el manejo de grapheme clusters), la Hoja de trucos de regex cubre los flags /u y /v y los escapes de propiedades Unicode.

Error 2: Dividir texto CJK por espacios en blanco para contar palabras

Síntoma: Un artículo chino de 500 caracteres se reporta como 1 palabra. La cotización de traducción basada en eso está errada por 500x.

Causa raíz: Los idiomas CJK no usan espacios entre palabras. text.split(/\s+/) devuelve un solo token que contiene el ensayo entero.

Corrección: Cuenten cada ideograma CJK como una palabra — la convención que usan Microsoft Word, Google Docs y todo procesador de palabras CJK nativo.

function countWordsMixed(text) {
  const cjk = (text.match(/[一-鿿぀-ヿ가-힯]/g) || []).length;
  const latin = (text
    .replace(/[一-鿿぀-ヿ가-힯]/g, ' ')
    .match(/[A-Za-z0-9]+(?:['’-][A-Za-z0-9]+)*/g) || []).length;
  return cjk + latin;
}

Los rangos Unicode cubren CJK Unified Ideographs (U+4E00 a U+9FFF), Hiragana y Katakana (U+3040 a U+30FF), y Hangul Syllables (U+AC00 a U+D7AF): los cuatro bloques que el conteo de palabras de Microsoft Word cuenta como ideogramas.

Error 3: Olvidar la sustitución de URL de 23 caracteres de Twitter

Síntoma: Un borrador muestra 320 caracteres en su contador, incluida una URL de 80 caracteres. Se pasan 10 minutos recortándolo, solo para darse cuenta de que Twitter habría aceptado el original a 263 caracteres.

Causa raíz: Twitter reemplaza cada URL con un enlace t.co de 23 caracteres al publicar. Su contador crudo no lo sabe.

Corrección: Pre-calculen la longitud publicada usando raw − URL_length + 23 por cada URL. Para borradores con múltiples URLs, sumen las correcciones. La detección de URL en contenido publicado sigue RFC 3986, las mismas reglas de parseo que recorre la guía de Codificación y decodificación de URL.

Error 4: Escribir meta description a 320 caracteres (guía vieja)

Síntoma: Crearon una meta description de 280 caracteres con el CTA al final. En los resultados de búsqueda de Google, la descripción se corta a media frase en el carácter 158 y el CTA nunca aparece.

Causa raíz: Entre diciembre de 2017 y mayo de 2018, Google expandió brevemente la visualización de la meta description a 320 caracteres. Muchos tutoriales SEO siguen citando ese número. Google revirtió a ~160 a mediados de 2018 y se ha mantenido ahí desde entonces.

Corrección: Escriban a 150-160 caracteres. Pongan la keyword primaria en los primeros 30 caracteres y el CTA en los últimos 30. Usen un simulador SERP preciso a nivel píxel para páginas de alto valor; los glifos anchos (W, M, K) consumen el presupuesto más rápido que los angostos (i, l, t).

Error 5: Confundir 280 caracteres con 280 palabras

Síntoma: Alguien del equipo escribe “necesitamos un tuit de 280 palabras” y produce 1,500 caracteres de prosa perfectamente decente. El tuit no se publica.

Causa raíz: Confusión entre caracteres y palabras. Las dos unidades difieren por aproximadamente 5-6x en prosa inglesa.

Corrección: Fijen la regla por plataforma. Twitter, SMS y meta SEO cuentan caracteres. NaNoWriMo, asignaciones académicas, contratos de traducción y la mayoría de los briefs de content marketing cuentan palabras. Ante la duda, revisen el propio contador de la plataforma (la caja de redacción de Twitter, Word > Revisar > Contar palabras) antes de cerrar la especificación.

Error 6: Pegar comillas tipográficas que cambian silenciosamente el SMS a UCS-2

Síntoma: Copian una plantilla de recibo de cliente desde un Google Doc a su emisor de SMS. El original tenía 145 caracteres y se enviaba como un segmento GSM-7. Después de pegar, son los mismos 145 caracteres pero se facturan como 2 segmentos UCS-2. El costo se duplica en una campaña de un millón de mensajes.

Causa raíz: Google Docs y Word convierten automáticamente " y ' a comillas tipográficas " " y ' '. Esas comillas no están en el conjunto de caracteres GSM-7, lo que cambia todo el mensaje a UCS-2.

Corrección: Normalicen antes de transmitir:

function toGsm7Quotes(s) {
  return s
    .replace(/[“”]/g, '"')   // " " → "
    .replace(/[‘’]/g, "'")   // ' ' → '
    .replace(/[–—]/g, '-');  // – — → -
}

Ejecútenlo antes de envíos sensibles a la facturación. Twilio, MessageBird y Bandwidth exponen un campo de codificación en la respuesta — regístrenlo y alerten cuando aparezca UCS-2 en plantillas que pensaron como GSM-7.

Preguntas frecuentes

¿Cuál es la diferencia entre conteo de caracteres y conteo de palabras?

El conteo de caracteres cuenta cada carácter, incluidos espacios, puntuación y emoji, medido por punto de código Unicode en la mayoría de las plataformas modernas. El conteo de palabras cuenta los tokens separados por espacios en blanco para escrituras latinas y un ideograma como una palabra para CJK. Twitter, SMS y las meta descriptions SEO usan conteo de caracteres. Los ensayos académicos, los manuscritos de NaNoWriMo y las facturas de traducción usan conteo de palabras.

¿Por qué Twitter cuenta un emoji como 1 carácter pero JavaScript los cuenta como 2?

Twitter mide por punto de código Unicode: cada emoji es un codepoint, un carácter. El string.length de JavaScript mide unidades de código UTF-16. La mayoría de los emoji están por encima de U+FFFF y se codifican como pares sustitutos en UTF-16, así que ocupan dos unidades de código y .length devuelve 2. Usen [...text].length o Array.from(text).length para obtener el conteo de codepoints que Twitter realmente cuenta.

¿Por qué el límite de caracteres SMS es a veces 160 y otras 70?

SMS usa codificación GSM-7 de 7 bits por defecto, lo que da 160 caracteres en una carga útil de 140 bytes. Si el mensaje contiene cualquier carácter fuera de GSM-7 (emoji, comillas tipográficas, CJK, latín acentuado más allá de un conjunto pequeño), el mensaje entero cambia a codificación UCS-2 de 16 bits y el límite por segmento baja a 70 caracteres. Un solo emoji en cualquier parte del mensaje dispara el cambio.

¿Cuál es la longitud ideal de meta description en 2026?

Apunten a 150-160 caracteres. El SERP de escritorio de Google trunca alrededor de 155-165 según el ancho de píxel; móvil corta entre 100 y 120. Por debajo de 120 caracteres Google a menudo reemplaza la descripción entera con un pasaje del cuerpo de la página. Empiecen con la keyword primaria en los primeros 30 caracteres y terminen con el CTA en los últimos 30, para que el mensaje sobreviva al truncamiento en cualquier dirección.

¿El límite de caracteres incluye espacios y emoji?

Sí, en prácticamente cada plataforma. Espacios, saltos de línea, puntuación y emoji cuentan cada uno como un punto de código Unicode. Hay dos excepciones que vale la pena conocer: SMS, donde los emoji disparan el cambio de codificación descrito arriba, y Bluesky, que cuenta grapheme clusters, así que un emoji de múltiples codepoints como la familia 👨‍👩‍👧‍👦 cuesta 1 carácter en vez de 7.

¿Cómo se calcula el conteo de palabras para texto chino, japonés y coreano?

Cada ideograma CJK cuenta como una palabra. Es la convención usada por el conteo de palabras de Microsoft Word en modo chino, Google Docs, los editores CJK nativos y todos los sistemas comerciales de memoria de traducción. Un ensayo chino de 500 caracteres se reporta como 500 palabras. El texto mixto cuenta los ideogramas CJK por carácter y los tokens latinos por espacios, sumando los dos.

¿Cómo maneja Twitter la longitud de las URLs dentro del límite de 280 caracteres?

Twitter envuelve automáticamente cada URL en un enlace corto t.co de 23 caracteres al publicar, sin importar la longitud original. La longitud publicada sigue la fórmula published = raw − URL_length + 23 por cada URL. Un borrador de 320 caracteres con una URL de 100 caracteres se envía como 243 caracteres. Twitter reconoce las URLs por patrones RFC 3986, así que las query strings y los fragments quedan absorbidos en el token de URL.

Lecturas relacionadas

Hoja de trucos de regex — coincidencia de patrones para validación de caracteres, escapes de propiedades Unicode
Guía de Text Diff en línea — comparar dos piezas de texto, línea por línea y carácter por carácter
Guía de codificación y decodificación de URL — reglas de escape de caracteres cuando el texto viaja por URLs
Entendiendo Base64 — la otra mitad de la codificación “bits a caracteres”, aplicada a email y datos binarios