Text Size Calculator
Compare text encodings and payload sizes in your browser.
How to use the calculator
- Paste text or inspect a local text file. The editor starts empty and keeps the original line endings.
- Choose an encoding, line-ending transformation and optional BOM. Read exact bytes and compare the serialized representations.
- Set an optional byte budget for the representation your API expects. Copy the original text, summary or complete encoded output explicitly.
- Read the highlighted size in automatically selected bytes, KB, MB or GB (TB/PB for larger values). Exact bytes remain below and beside other large results. Readable sizes are rounded; budget checks always use exact bytes.
Understanding bytes, encodings and payloads
A byte is eight bits; a visible character can contain multiple Unicode code points. 😀 is one grapheme, one code point and two UTF-16 units: 4 bytes in UTF-8, UTF-16 and UTF-32. Combining marks and ZWJ emoji sequences make character counts differ from byte counts.
UTF-8 uses 1–4 bytes per Unicode scalar; UTF-16 uses 2 or 4 and UTF-32 uses 4. A takes 1/2/4 bytes respectively. Cyrillic, Arabic, Chinese and emoji are valid text, even when they need more bytes. These are encoded content sizes, not JavaScript heap use or allocated disk space.
No normalization, trimming or invisible-character removal occurs. Composed é uses 2 UTF-8 bytes; e + U+0301 uses 3. Both are usually one grapheme. The original source is preserved: only the selected line-ending transformation creates effective text for results.
An added BOM costs 3 bytes in UTF-8, 2 in UTF-16 or 4 in UTF-32, even for empty text. A literal leading U+FEFF remains content. LF uses one ASCII byte; CRLF uses two. Conversion handles CRLF together, then lone CR/LF, leaving NEL, U+2028 and U+2029 unchanged.
For A space B, UTF-8 is 3 bytes, URL output A%20B is 5, and form value A+B is 3. A followed by CRLF then B is 4 UTF-8 bytes, or 3 after LF conversion; its preserved JSON string is 8 bytes. JSON includes outer quotes and escapes: it serializes the input as one string rather than minifying a JSON document.
Base64 is an encoding, not compression or encryption. Standard padded output has 4 × ceil(byteLength / 3) ASCII bytes, approaching one-third overhead for long input. UTF-8 A becomes QQ== (4 bytes). Empty input without a BOM produces empty Base64; an empty JSON string still takes 2 bytes.
File.size is the immutable original byte count, including its signature. File import supports UTF-8 and UTF-16LE/BE with strict decoding. A recognized BOM chooses the decoder and is removed exactly once; additional U+FEFF content is retained. Without a signature UTF-8 is assumed, not reliably detected. Re-encoding can differ because of encoding, line endings, BOM policy or edits.
For an API field limit, check whether the service counts raw text, a JSON string or URL/form data. This calculator excludes property names, object wrappers, field names, equals signs and HTTP headers. A zero budget accepts only an empty representation; equality fits exactly. Database and platform rules may differ. Use related tools for word counts, social limits and SMS segments.
Local processing and scope
Processing happens locally. This tool does not upload entered text or files. The site’s shared analytics and advertising may make network requests.
Frequently asked questions
Sources
Sources reviewed: 2026-09-13. Algorithms follow these specifications; the date is not an accuracy guarantee.Related tools
SMS Character Counter & Segment Calculator
See how your message is encoded, where its segments end and what it may cost. Your text stays in your browser.
Open tool — SMS Character Counter & Segment CalculatorSocial Media Character Counter
Check platform-specific limits and split posts without losing text.
Open tool — Social Media Character CounterCharacter Counter
Count characters, words, sentences and paragraphs. Check word density, reading time and UTF-8 size, all in your browser.
Open tool — Character Counter