How Word, Grapheme, and UTF-8 Byte Counters Actually Work

1. Why Graphemes, UTF-16 Code Units, and UTF-8 Bytes Differ

In ASCII text (characters U+0000 through U+007F), one visible character equals one UTF-16 code unit and one UTF-8 byte. Outside basic ASCII, those three measurements diverge immediately.

JavaScript stores strings internally as sequences of 16-bit UTF-16 code units. Any Unicode code point above U+FFFF (such as mathematical symbols, historic scripts, or pictographs) requires a surrogate pair of two UTF-16 code units (string.length === 2) and four UTF-8 bytes. When multiple code points are joined by a Zero-Width Joiner (U+200D) or followed by a combining diacritical mark (such as "e" + U+0301), a single visible grapheme cluster can span 2 to 11 UTF-16 code units and up to 25 UTF-8 bytes.

2. Word and Sentence Boundaries Under Unicode UAX #29

Naive word counters that split strings on whitespace (text.split(/\s+/)) miscount punctuation-only tokens as words, break on em-dashes, and fail completely on scripts without spaces between words (such as Japanese, Thai, or Chinese).

FetchToolKit uses the browser-native Intl.Segmenter API configured with granularity: "word" and granularity: "sentence", filtering segments where segment.isWordLike is true. This follows Unicode Standard Annex #29 (UAX #29) text boundary rules directly inside your browser.

const graphemeSegmenter = new Intl.Segmenter('en', { granularity: 'grapheme' });
const wordSegmenter = new Intl.Segmenter('en', { granularity: 'word' });

const graphemes = Array.from(graphemeSegmenter.segment(input)).length;
const words = Array.from(wordSegmenter.segment(input)).filter((s) => s.isWordLike).length;
const utf8Bytes = new TextEncoder().encode(input).byteLength;

3. Reference Table of Social, SEO, and Messaging Character Limits

When writing meta descriptions, social posts, or SMS notifications, exceeding a platform cap truncates your message or splits an SMS into multiple billed segments.