String Length Calculator

Why does "string length" have three different answers?

Paste any text and this tool reports its length in three genuinely different units, because "how long is this string?" doesn't have one universal answer:

• JS String Length — the raw .length property most tools report, counted in UTF-16 code units. JavaScript strings are stored as UTF-16, and any character outside the Basic Multilingual Plane — most emoji, some rare CJK characters — is stored as a surrogate pair, two code units for one visible character. A single 😀 emoji has .length === 2, even though it's clearly one character. This is the number that misleads naive length checks (e.g. "max 10 characters" input validation that actually cuts an emoji in half).
• Unicode Character Count (Codepoints) — the true number of Unicode characters, computed by spreading the string ([...text].length), which iterates codepoint by codepoint instead of code-unit by code-unit. Here 😀 correctly counts as 1. This is almost always what a person means by "character count."
• Byte Length (UTF-8) — the size the text would occupy once UTF-8-encoded (TextEncoder), the encoding used by virtually every API, database column and file on disk. A 😀 emoji is 4 bytes in UTF-8. This is the number that matters for storage limits, network payloads, and any "max N bytes" constraint — plain ASCII text has identical JS length, codepoint count and byte length, but the moment accented letters, CJK text or emoji show up, all three diverge.

Alongside these, the tool also reports character count excluding whitespace, word count, and line count.

A note on grapheme clusters

There's a fourth, even more human-centric unit: the grapheme cluster — what a person perceives as "one character" on screen. An emoji with a skin-tone modifier (👍🏽) or a letter with a combining accent mark is multiple Unicode codepoints but renders as a single visual glyph, so codepoint count can still overcount from a human's perspective. Full grapheme-cluster segmentation needs Intl.Segmenter and locale-aware rules that go beyond a simple length calculation; this tool intentionally reports codepoint count rather than an approximate grapheme count, so the numbers shown are always exact, not a best-effort estimate.

Who is it for?

• Developers validating input length limits, especially against APIs or databases that cap by bytes, not characters.
• Anyone working with emoji, CJK text, or accented characters who has been confused by inconsistent length numbers between tools.
• Content and localization teams checking whether translated or emoji-laden text will fit a byte-limited field (SMS, tweet, database column).

How to use it

1. Type or paste text into the box — stats update live as you type.
2. Or drop a text file onto the uploader to analyze its contents.
3. Compare the three length metrics to see exactly where — and by how much — they diverge for your text.

Privacy

All calculation happens entirely in your browser. Your text never leaves your device.