Calculadora de tamaño de texto

Cómo usar la calculadora

1. Pega texto o examina un archivo local. El editor empieza vacío y conserva los saltos de línea originales.
2. Elige codificación, conversión de saltos y BOM opcional. Consulta los bytes exactos y compara las representaciones serializadas.
3. Define un límite opcional para la representación que espera tu API. Copia el original, el resumen o el resultado completo con los botones.
4. Lee el tamaño destacado en la unidad seleccionada automáticamente: bytes, KB, MB o GB (TB/PB para valores mayores). Los bytes exactos se muestran debajo y junto a los demás resultados grandes. Los tamaños legibles se redondean; los límites siempre se comprueban con bytes exactos.

Funciones

• Compara tamaños en UTF-8, UTF-16 y UTF-32
• Muestra bytes exactos y el efecto de los saltos de línea y el BOM
• Comprueba un límite de bytes opcional
• Muestra la salida codificada para copiarla cuando lo decidas
• Permite examinar cuánto aporta cada carácter al tamaño

Casos de uso

• Comprobar el tamaño de una carga para una API
• Comparar codificaciones de un archivo de texto local
• Elegir saltos de línea y BOM para una exportación
• Comparar el tamaño del texto en Base64 y codificado para URL

Entender bytes, codificaciones y datos

Un byte tiene ocho bits; un carácter visible puede contener varios puntos de código Unicode. 😀 es un grafema, un punto y dos unidades UTF-16: 4 bytes en UTF-8, UTF-16 y UTF-32. Las marcas combinantes y secuencias ZWJ hacen que caracteres y bytes no coincidan.

UTF-8 usa 1–4 bytes por valor escalar Unicode; UTF-16 usa 2 o 4 y UTF-32 usa 4. A ocupa 1/2/4 bytes, respectivamente. El cirílico, árabe, chino y los emojis son texto válido aunque ocupen más bytes. Son tamaños del contenido codificado, no de la memoria JavaScript ni del espacio asignado en disco.

No se normaliza, recortan espacios ni eliminan caracteres invisibles. é compuesto usa 2 bytes UTF-8; e + U+0301 usa 3. Ambos suelen ser un grafema. El original se conserva: solo la conversión de saltos elegida crea el texto efectivo.

El BOM añadido ocupa 3 bytes en UTF-8, 2 en UTF-16 o 4 en UTF-32, incluso con texto vacío. Un U+FEFF inicial literal sigue siendo contenido. LF usa un byte ASCII; CRLF usa dos. La conversión trata CRLF como par y después CR/LF aislados, conservando NEL, U+2028 y U+2029.

Para A espacio B, UTF-8 ocupa 3 bytes, A%20B en URL ocupa 5 y A+B en formulario ocupa 3. A seguido de CRLF y B ocupa 4 bytes UTF-8, o 3 tras convertir a LF; la cadena JSON conservada ocupa 8. JSON incluye comillas externas y escapes: serializa la entrada como una cadena, sin minimizar un documento JSON.

Base64 es codificación, no compresión ni cifrado. La salida estándar con relleno ocupa 4 × ceil(byteLength / 3) bytes ASCII, acercándose a un tercio de sobrecarga para entradas largas. A en UTF-8 pasa a QQ== (4 bytes). El texto vacío sin BOM genera Base64 vacío; una cadena JSON vacía sigue ocupando 2 bytes.

File.size es el recuento original inmutable, incluida la firma. La importación admite UTF-8 y UTF-16LE/BE con decodificación estricta. Un BOM reconocido elige el decodificador y se elimina una sola vez; los U+FEFF adicionales se conservan. Sin firma, UTF-8 es una suposición, no una detección fiable. La recodificación puede diferir por codificación, saltos, BOM o ediciones.

Para límites de campos API, comprueba si el servicio cuenta texto sin serializar, cadena JSON o datos URL/formulario. La calculadora excluye nombres de propiedades, objetos externos, nombres de campos, signos igual y cabeceras HTTP. Un límite cero acepta solo representaciones vacías; la igualdad cabe exactamente. Las reglas de bases de datos y plataformas pueden diferir. Usa las herramientas relacionadas para palabras, redes sociales y segmentos SMS.

Procesamiento local y alcance

El procesamiento es local. Esta herramienta no sube el texto ni los archivos introducidos. Los servicios de análisis y publicidad del sitio pueden hacer solicitudes de red.