Calculadora de tamanho de texto

Como usar a calculadora

1. Cole texto ou inspecione um arquivo local. O editor começa vazio e preserva as quebras de linha originais.
2. Escolha a codificação, a conversão de quebras e o BOM opcional. Veja os bytes exatos e compare as representações serializadas.
3. Defina um limite opcional para a representação esperada pela API. Copie o original, o resumo ou a saída codificada completa com os botões.
4. Leia o tamanho em destaque na unidade escolhida automaticamente: bytes, KB, MB ou GB (TB/PB para valores maiores). Os bytes exatos ficam abaixo e ao lado dos outros resultados grandes. Os tamanhos legíveis são arredondados; os limites sempre usam bytes exatos.

Recursos

• Compara tamanhos em UTF-8, UTF-16 e UTF-32
• Mostra bytes exatos e o efeito das quebras de linha e do BOM
• Confere um limite de bytes opcional
• Mostra a saída codificada para copiar quando você quiser
• Examina quanto cada caractere contribui para o tamanho

Quando usar

• Verificar o tamanho de um payload de API
• Comparar codificações de um arquivo de texto local
• Escolher quebras de linha e BOM para exportar
• Comparar o tamanho do texto em Base64 e codificado para URL

Entenda bytes, codificações e dados

Um byte tem oito bits; um caractere visível pode conter vários pontos de código Unicode. 😀 é um grafema, um ponto e duas unidades UTF-16: 4 bytes em UTF-8, UTF-16 e UTF-32. Marcas combinantes e sequências ZWJ fazem a contagem de caracteres diferir da de bytes.

UTF-8 usa 1–4 bytes por valor escalar Unicode; UTF-16 usa 2 ou 4 e UTF-32 usa 4. A ocupa 1/2/4 bytes, respectivamente. Cirílico, árabe, chinês e emojis são textos válidos, mesmo ocupando mais bytes. São tamanhos do conteúdo codificado, não da memória JavaScript ou do espaço alocado no disco.

Não há normalização, corte de espaços ou remoção de caracteres invisíveis. é composto usa 2 bytes UTF-8; e + U+0301 usa 3. Ambos costumam ser um grafema. O original é preservado: apenas a conversão de quebras escolhida cria o texto efetivo.

O BOM adicionado ocupa 3 bytes em UTF-8, 2 em UTF-16 ou 4 em UTF-32, mesmo com texto vazio. Um U+FEFF inicial literal continua sendo conteúdo. LF usa um byte ASCII; CRLF usa dois. A conversão trata CRLF como par e depois CR/LF isolados, preservando NEL, U+2028 e U+2029.

Para A espaço B, UTF-8 ocupa 3 bytes, A%20B na URL ocupa 5 e A+B no formulário ocupa 3. A seguido de CRLF e B ocupa 4 bytes UTF-8, ou 3 após conversão LF; a string JSON preservada ocupa 8. JSON inclui aspas externas e escapes: serializa a entrada como uma string, sem minificar um documento JSON.

Base64 é codificação, não compressão nem criptografia. A saída padrão com preenchimento ocupa 4 × ceil(byteLength / 3) bytes ASCII, aproximando-se de um terço de acréscimo para entradas longas. A em UTF-8 vira QQ== (4 bytes). Texto vazio sem BOM gera Base64 vazio; uma string JSON vazia ainda ocupa 2 bytes.

File.size é a contagem original imutável, incluindo a assinatura. A importação suporta UTF-8 e UTF-16LE/BE com decodificação estrita. Um BOM reconhecido escolhe o decodificador e é removido uma única vez; U+FEFF adicional é preservado. Sem assinatura, UTF-8 é uma suposição, não detecção confiável. A recodificação pode diferir por codificação, quebras, BOM ou edições.

Para limites de campos de API, confirme se o serviço conta texto bruto, string JSON ou dados URL/formulário. A calculadora exclui nomes de propriedades, objetos externos, nomes de campos, sinais de igual e cabeçalhos HTTP. Limite zero aceita apenas representação vazia; igualdade cabe exatamente. Regras de bancos e plataformas podem diferir. Use as ferramentas relacionadas para palavras, redes sociais e segmentos SMS.

Processamento local e escopo

O processamento é local. Esta ferramenta não envia textos ou arquivos inseridos. Os serviços de análise e publicidade do site podem fazer solicitações de rede.