Contador de bytes

Cómo funciona

1. Escribe o pega el texto: Escribe o pega cualquier texto en el campo de entrada.
2. Ve el recuento de bytes: La herramienta muestra al instante el recuento de bytes en UTF-8, UTF-16, ASCII y otras codificaciones lado a lado.
3. Comprueba los límites: Compara el recuento de bytes con los límites habituales (SMS: 160 caracteres, HTTP headers: 8 KB, campos de base de datos, etc.) para ver si tu contenido encaja.

¿Por qué usar Contador de bytes?

El recuento de caracteres y el recuento de bytes no son lo mismo. Un solo emoji puede ocupar 4 bytes en UTF-8. Los caracteres chinos y árabes ocupan 2-3 bytes cada uno. Muchos sistemas imponen límites de bytes, no de caracteres, incluyendo campos VARCHAR de MySQL, valores de Redis, HTTP headers, mensajes SMS y nombres de objetos de almacenamiento en la nube. El Contador de bytes revela el tamaño real en bytes de tu texto en cada codificación para que puedas mantenerte dentro de las restricciones del sistema.

Características

• Múltiples tamaños de codificación: Muestra el recuento de bytes para UTF-8, UTF-16 LE/BE, UTF-32 y Latin-1.
• Desglose de caracteres: Cuenta total de caracteres, puntos de código Unicode y caracteres multibyte por separado.
• Preajustes de límites habituales: Compara con SMS (160), tweet (280), meta descripción (160), límites VARCHAR de MySQL y más.
• Actualizaciones en vivo: El recuento de bytes se actualiza en tiempo real mientras escribes.
• Comparación de codificaciones: Ve qué codificación es más compacta para tu texto específico.

Preguntas frecuentes

¿Por qué mi recuento de bytes es mayor que mi recuento de caracteres?

Muchos caracteres ocupan más de 1 byte en UTF-8. Los caracteres ASCII (A-Z, 0-9, puntuación) son 1 byte cada uno. Los caracteres latinos extendidos (letras acentuadas) son 2 bytes. Los caracteres chinos, japoneses, coreanos y árabes suelen ser 3 bytes. Los emojis suelen ser 4 bytes.

¿Qué codificación usan la mayoría de los sistemas web?

UTF-8 es la codificación dominante para contenido web, APIs, JSON y bases de datos. MySQL y PostgreSQL usan UTF-8 de forma predeterminada. Al verificar los límites de bytes, utiliza la columna UTF-8 a menos que tu sistema indique lo contrario.

¿Por qué los mensajes SMS tienen un límite de 160 caracteres?

Los SMS tradicionales utilizan la codificación GSM de 7 bits, que permite 160 caracteres por segmento. Cuando incluyes cualquier carácter no GSM (como una comilla tipográfica, un emoji o una letra no latina), el mensaje cambia a la codificación UCS-2, que reduce el límite a 70 caracteres por segmento.

¿Qué es realmente un byte?

Un byte son 8 bits, que pueden contener 256 valores distintos. En el texto, esos 256 valores se asignan a caracteres mediante una codificación, un libro de reglas que dice «esta secuencia de bytes equivale a este carácter». La misma cadena de bytes puede significar texto completamente diferente bajo distintas codificaciones: el byte 0xE9 es «é» en Latin-1, el inicio de una secuencia de 3 bytes en UTF-8, o parte de una unidad de código UTF-16. La codificación es toda la historia.

Cuando guardas texto en disco, lo envías por la red o lo almacenas en una base de datos, lo que realmente se conserva son bytes, no caracteres. El recuento de caracteres que ves en un editor de texto se calcula al mostrarlo, tras decodificar los bytes. Si la codificación no coincide en alguno de los dos lados, obtienes mojibake: texto decodificado con la codificación equivocada que aparece como galimatías (el clásico é en lugar de é cuando los bytes Windows-1252 se leen como UTF-8).

El conteo de bytes es lo que miden los límites de columnas de bases de datos, los búferes de encabezados HTTP, las cargas útiles SMS y las claves de objetos de almacenamiento en la nube, sin importar cómo «parezca» el texto. Este contador reporta el tamaño en bytes en las cuatro codificaciones que más probablemente te importarán: UTF-8 (el estándar moderno), UTF-16 (el formato interno de Windows / Java / JavaScript), ASCII (solo válido para texto latino inglés) y Latin-1 (un recurso de un byte heredado). El recuento de caracteres al lado se da como referencia.

UTF-8: la historia

UTF-8 fue esbozado por Ken Thompson y Rob Pike en Bell Labs en la noche del 2 de septiembre de 1992, según se cuenta sobre un mantel individual en un diner de Nueva Jersey, después de que el equipo de Plan 9 necesitara una codificación de longitud variable compatible con ASCII para Unicode. El diseño lleva tres propiedades que casi nada más tiene a la vez: el texto ASCII también es UTF-8 válido (1 byte por carácter, bytes idénticos), la codificación es auto-sincronizante (los bits altos de cualquier byte te dicen si inicia un nuevo carácter o continúa uno existente), y no hay ambigüedad de orden de bytes. Esas tres propiedades juntas explican por qué UTF-8 desplazó a todas las codificaciones competidoras en la web.

Se estandarizó primero como RFC 2044 en octubre de 1996, revisado como RFC 2279 en enero de 1998, y reemplazado por el actual RFC 3629 (noviembre de 2003), que limitó UTF-8 a 4 bytes por carácter para coincidir con el techo final de puntos de código Unicode en U+10FFFF. W3Techs ha rastreado el uso de codificaciones en la web pública continuamente desde 2010; UTF-8 pasó del 56 % de los sitios web en 2011 a aproximadamente el 98 % en 2026. La especificación HTML5 obliga a UTF-8 para el contenido nuevo; HTTP/2 y HTTP/3 envían encabezados en UTF-8 vía HPACK / QPACK; RFC 8259 obliga a UTF-8 para el intercambio JSON entre sistemas. Si tienes que elegir una codificación para todo, la respuesta de los últimos 15 años ha sido UTF-8 y la respuesta para los próximos 15 será la misma.

UTF-8 es de longitud variable, de 1 a 4 bytes por carácter:

Consecuencia práctica: el texto inglés en UTF-8 promedia ~1 byte por carácter; el chino ~3 bytes; un mensaje rico en emoji puede alcanzar 4 bytes por carácter visible, y los emoji combinados (secuencias ZWJ de familia) fácilmente llegan a 20-30 bytes por lo que parece un solo carácter.

UTF-16 y la trampa de las parejas suplentes

UTF-16 fue la codificación de elección para Windows NT (1993), Java 1.0 (1996), JavaScript (1995), .NET y Mac OS X Cocoa NSString. Usa 2 bytes para cada carácter del plano multilingüe básico (U+0000 – U+FFFF), y parejas suplentes para todo lo de afuera: un suplente alto (D800–DBFF) más un suplente bajo (DC00–DFFF), 4 bytes en total. UTF-16 necesita una marca de orden de bytes (BOM) en disco para distinguir el big-endian (UTF-16BE, FE FF) del little-endian (UTF-16LE, FF FE); Windows usa little-endian por defecto.

La trampa: en JavaScript, "😀".length === 2. MDN lo dice directamente: la propiedad length «contiene la longitud de la cadena en unidades de código UTF-16». Por eso un solo emoji como 😄 reporta una longitud de 2 (vive en el plano suplementario y necesita una pareja suplente), y la secuencia ZWJ de familia 👨‍👩‍👧‍👦 reporta una longitud de 11 (cuatro emoji de 2 unidades de código más tres uniones de ancho cero). El mismo emoji de familia de un carácter cuenta como 11 en JavaScript, 5 en Python 3 y 1 en Swift, según el modelo de cadena de cada lenguaje. Para conteos de caracteres visibles correctos en JavaScript, usa Intl.Segmenter con granularidad grapheme (todos los navegadores evergreen desde 2021).

ASCII, Latin-1 y el caos pre-Unicode

ASCII (American Standard Code for Information Interchange) se estandarizó como ASA X3.4-1963, revisado como X3.4-1968 y otra vez como ANSI X3.4-1986. Un código de 7 bits, 128 caracteres: 95 imprimibles más 33 de control. Los 33 caracteres de control incluyen herencias de teletipo como BEL, BS, CR, LF, DEL, y algunos que sobreviven en los protocolos modernos (NUL, TAB, LF, CR, ESC). ASCII todavía funciona como un subconjunto estricto de UTF-8, por lo que el «texto ASCII puro» también es UTF-8 válido y por lo que la migración a UTF-8 fue indolora para los sistemas solo en inglés.

Latin-1 / ISO-8859-1 (1987) era una extensión de un byte con 256 caracteres que añadía letras acentuadas de Europa Occidental, símbolos monetarios y puntuación común. Fue la codificación de hecho para el contenido web occidental desde 1995 hasta que UTF-8 la desplazó alrededor de 2008. Windows-1252 es el superconjunto de Latin-1 de Microsoft, que añade «comillas tipográficas», guiones largos y el símbolo del euro en el rango de control C1 (0x80-0x9F); cuando se envían archivos CSV por correo entre Mac y Windows, esa es la fuente del clásico mojibake é cuando un lado lee bytes Windows-1252 como UTF-8.

La trampa «utf8» de MySQL

MySQL arrastra una verruga de juego de caracteres notoria desde la versión 4.1: el alias de juego de caracteres utf8 no es realmente UTF-8. Es un subconjunto de máximo 3 bytes que no puede representar caracteres por encima de U+FFFF, lo que significa que no puede almacenar emoji ni caracteres del plano suplementario. Insertar «🎉» en una columna utf8 produce «?» o un error según sql_mode. La solución es utf8mb4, añadido en MySQL 5.5.3 (marzo de 2010); MySQL 8.0 (abril de 2018) lo hizo el nuevo predeterminado. Pero los esquemas creados antes de 8.0 a menudo todavía usan la versión de 3 bytes por defecto. Si ves emoji desapareciendo silenciosamente desde la entrada del usuario, esto es casi siempre la causa. PostgreSQL no tiene una trampa equivalente, acepta UTF-8 verdadero de forma nativa.

SMS, GSM-7 y la carga útil de 160 bytes

El límite de 160 caracteres SMS se remonta a un cálculo de Friedhelm Hillebrand en 1985, un ingeniero del Grupo de Trabajo GSM que supuestamente se sentó en su máquina de escribir, tecleó oraciones aleatorias y contó que «la mayoría de los mensajes pueden expresarse en 160 caracteres o menos». Los 160 se dedujeron hacia atrás para encajar en una carga útil de 140 bytes usando un alfabeto de 7 bits (140 × 8 ÷ 7 = 160). Los detalles de la codificación están formalizados en 3GPP TS 23.038 (originalmente GSM 03.38), y todavía gobiernan la facturación SMS hoy.

En bytes: un SMS único son 140 bytes en la línea. Con GSM-7 eso son 160 caracteres; con UCS-2 (una codificación de ancho fijo de 2 bytes usada para todo lo de afuera del alfabeto GSM-7) son 70. Los mensajes multi-parte pierden 7 caracteres GSM-7 o 3 caracteres UCS-2 por segmento a favor de un encabezado de datos de usuario (User Data Header) usado para el reensamblaje, por lo que los mensajes largos se limitan a 153 caracteres GSM-7 por segmento o 67 caracteres UCS-2 por segmento. Una sola comilla tipográfica, guion largo o emoji rebaja todo el mensaje a UCS-2 y divide a la mitad el límite por segmento. El «Smart Encoding» de Twilio sustituye automáticamente las comillas curvas por rectas para mantener las campañas de marketing en la codificación más barata.

Dónde muerden de verdad los límites en bytes

Tres categorías donde los límites en bytes (y no en caracteres) te atrapan:

Encabezados de petición HTTP. Sin máximo en la especificación formal, cada servidor impone uno. El LimitRequestFieldSize de Apache es 8 KB por encabezado por defecto; los large_client_header_buffers de Nginx son 4 × 8 KB por defecto; IIS es 16 KB; el AWS Application Load Balancer acepta 16 KB por encabezado y 60 KB en total; Cloudflare permite 32 KB. Los JWT con conjuntos de claims abultados rutinariamente exceden el 8 KB por defecto de Apache, que es el modo de fallo en producción más común para autenticación basada en tokens.

Claves de objetos de almacenamiento en la nube. S3 y GCS limitan las claves de objeto a 1024 bytes de UTF-8. Azure Blob Storage limita los nombres de blob a 1024 caracteres (UTF-16 interno). Para S3, un nombre de archivo rico en CJK (3 bytes por carácter) tope a ~341 caracteres; uno rico en emoji (4 bytes por carácter) a ~256, mucho antes de lo que el desarrollador espera.

Límites de filas e índices de bases de datos. MySQL InnoDB tiene un tamaño de fila de 65.535 bytes y un límite de prefijo de clave de índice de 3072 bytes en el formato de fila DYNAMIC (767 en el más antiguo COMPACT). Una columna VARCHAR(255) utf8mb4 necesita 1020 bytes (255 × 4) de espacio de índice, bien en DYNAMIC, roto en COMPACT. Los documentos BSON de MongoDB topan en 16 MB. Los elementos DynamoDB topan en 400 KB (incluyendo nombres de atributos). Los valores Redis topan en 512 MB.

Casos de uso comunes

• Validación de campos de base de datos, confirmar que un nombre enviado por el usuario cabrá antes del INSERT, especialmente cuando la columna es VARCHAR(255) utf8mb4 y la entrada es CJK.
• Copy de marketing SMS, confirmar que el mensaje se mantiene en GSM-7 (~1 byte por carácter visible en la carga útil) en lugar de caer accidentalmente en UCS-2 por una comilla tipográfica.
• Presupuesto de carga útil de API, confirmar que un cuerpo JSON cabe bajo un límite conocido (DynamoDB 400 KB, carga útil de AWS Lambda 6 MB síncrono, 256 KB asíncrono).
• Claves de objetos en la nube, confirmar que una clave S3 / GCS se mantiene bajo 1024 bytes tras la transducción no-ASCII.
• Divulgación de emoji, ver exactamente cuánto «peso» añade un emoji o una secuencia ZWJ de familia a una cadena.
• Selección de codificación, comparar los tamaños en bytes UTF-8 vs UTF-16; para contenido predominantemente CJK, UTF-16 puede ser más compacto (2 bytes por carácter CJK vs 3 en UTF-8).

Errores comunes

1. Confiar en .length de JavaScript para el tamaño en bytes. .length devuelve unidades de código UTF-16, no bytes ni caracteres. Para bytes UTF-8, usa new TextEncoder().encode(text).length; para caracteres visibles, usa Intl.Segmenter.
2. Asumir que MySQL utf8 es realmente UTF-8. Es un subconjunto de 3 bytes que descarta silenciosamente los emoji. Usa siempre utf8mb4 (y utf8mb4_unicode_ci para la colación) en cualquier columna que toque texto enviado por el usuario.
3. Asumir que un emoji equivale a un byte. Un solo emoji son 4 bytes en UTF-8, 4 bytes en UTF-16 (pareja suplente). Una secuencia ZWJ de familia puede exceder 30 bytes para lo que parece un solo carácter.
4. Contar un BOM UTF-8 como contenido. El BOM UTF-8 de tres bytes EF BB BF al principio de un archivo es metadato, no texto. La mayoría de las herramientas CLI (awk, head, sed) lo tratan como parte del primer campo, que es la fuente de muchos errores «¿por qué mi primer nombre de columna tiene un carácter extraño?».
5. Reportar un conteo de «bytes ASCII» para texto no ASCII. ASCII no puede representar caracteres por encima de U+007F. Este contador advierte cuando la entrada contiene no-ASCII para que sepas que la columna ASCII no es significativa.

Más preguntas frecuentes

¿Por qué un emoji son 4 bytes cuando los caracteres de texto son solo 1?

UTF-8 usa 1 byte para ASCII (U+0000 a U+007F), 2 bytes para latín extendido / griego / cirílico / árabe / hebreo (U+0080 a U+07FF), 3 bytes para la mayoría de escrituras CJK e índicas (U+0800 a U+FFFF), y 4 bytes para emoji y caracteres del plano suplementario (U+10000 a U+10FFFF). Un emoji típico como 😀 (U+1F600) está en el plano suplementario y cuesta 4 bytes. Los emoji combinados (por ejemplo, familia 👨‍👩‍👧‍👦) se construyen de varios emoji base pegados con uniones de ancho cero; cada emoji base son 4 bytes, cada unión son 3 bytes, así que una familia de 4 toma 4×4 + 3×3 = 25 bytes por lo que parece un carácter.

¿Qué significa realmente MySQL utf8?

En MySQL, el alias de juego de caracteres utf8 es un subconjunto de máximo 3 bytes del UTF-8 real. Puede codificar cada carácter del plano multilingüe básico de Unicode pero no puede almacenar emoji ni ningún carácter por encima de U+FFFF. El UTF-8 real de 4 bytes en MySQL es utf8mb4, disponible desde MySQL 5.5.3 (marzo de 2010), predeterminado desde MySQL 8.0 (abril de 2018). Si puedes cambiar el esquema, usa siempre utf8mb4 con la colación utf8mb4_0900_ai_ci (o utf8mb4_unicode_ci en servidores más antiguos).

¿Este contador incluye una marca de orden de bytes UTF-8?

No. La marca de orden de bytes UTF-8 son los tres bytes EF BB BF que Excel en Windows requiere al inicio de un archivo para detectar UTF-8. El contador mide los bytes del texto que pegas; si tu texto comienza con un BOM, esos tres bytes se cuentan como contenido. Si quieres saber si los bytes de tu archivo alcanzarán un límite, pega solo el cuerpo del archivo, no el BOM.

¿Por qué mi texto chino muestra 3 bytes por carácter en UTF-8?

Casi todos los ideogramas CJK están en el rango Unicode U+4E00 a U+9FFF (el bloque CJK Unified Ideographs), que UTF-8 codifica como 3 bytes cada uno. Una oración china de 100 caracteres es por tanto 300 bytes UTF-8. En UTF-16 el mismo texto son 200 bytes (2 bytes por carácter), así que UTF-16 es más compacto para contenido predominantemente CJK. UTF-8 gana para contenido mixto latino-y-CJK porque los caracteres latinos cuestan 1 byte cada uno en lugar de 2.

¿Se sube mi texto a algún sitio?

No. El contador de bytes funciona enteramente en tu navegador. Los conteos de bytes UTF-8 vienen de la API estándar TextEncoder (todos los navegadores modernos la soportan), los conteos UTF-16 y Latin-1 vienen de bucles simples. No hay petición de red, no hay llamada al servidor, no hay registro. Una vez cargada la página, la herramienta funciona sin conexión. Seguro para inspeccionar tokens de API, datos internos o cualquier cosa que no pegarías en un contador de texto de terceros.