A “character” can mean a UTF-16 code unit, a Unicode code point, or a grapheme cluster that a reader perceives as one unit. Intl.Segmenter helps JavaScript work with locale-sensitive grapheme, word, and sentence boundaries. It does not analyze glyph shape or meaning. ECMA-402 Unicode UAX #29

Conceptual illustration distinguishing UTF-16 units from user-perceived grapheme boundaries

Conceptual illustration, not runtime output or a browser measurement.

Why “character” can mean different things

JavaScript strings are indexed in UTF-16 code units, so length and a simple index are not necessarily a count of what a reader perceives as characters. A code point may occupy more than one code unit. A visible letter may combine a base character and a combining mark, and an emoji sequence can contain multiple code points. These are different units: code units, code points, and grapheme clusters. A grapheme cluster is a useful approximation of a user-perceived character, not a promise about glyph shape or screen width. Unicode UAX #29

What Intl.Segmenter returns

Intl.Segmenter is a standard JavaScript API that segments text according to a locale and a granularity: grapheme, word, or sentence. For example, create new Intl.Segmenter("ja", { granularity: "word" }), then iterate over segment(text). Each result exposes the segment, the input text, and an index for its start. That index is a UTF-16 code-unit offset into the original string. Word-granularity results can include isWordLike; this property is specific to word segmentation and is not a universal tag on every segment. ECMA-402 MDN

Choose the granularity for the task

Use grapheme segmentation when a text operation should avoid splitting a combining sequence or multi-code-point emoji. Word segmentation can help tokenize text for search or navigation, while sentence segmentation can locate candidate sentence boundaries. The output still includes punctuation and whitespace segments, so a word count should filter non-word-like items rather than count every yielded segment. isWordLike is a boundary classification, not a part-of-speech tag, stemmer, translation, or semantic analysis. UAX #29 supplies default boundary rules and allows tailoring; segmentation does not solve every language-processing task. MDN Unicode UAX #29

Do not treat an index as a display position

The index field locates a segment in the original UTF-16 string. It is not the segment number, Unicode code-point count, or screen-column position. A supplementary-plane symbol before a segment can make the UTF-16 offset differ from a code-point offset. Font shaping, line wrapping, bidirectional layout, and glyph width are separate rendering concerns. An editor can use segmentation to avoid breaking a grapheme, but it still needs its layout engine to map text offsets to pixels and cursor movement. ECMA-402 Unicode UAX #29

Expert perspective: locale and runtime data affect results

Word boundaries in some languages cannot be inferred from spaces alone, which is why locale-sensitive behavior and dictionary mechanisms matter. Unicode specifies default grapheme, word, and sentence boundaries, but some languages need tailoring or dictionary support. The observed result also depends on the Unicode and internationalization data shipped by a runtime; a newer specification does not mean every deployed browser immediately uses that version. MDN’s API reference explains that resolvedOptions() exposes the resolved locale and granularity. It does not identify the runtime’s Unicode data version, so test support and behavior in the target environment. Do not claim a tested browser or Unicode version without running it. Unicode UAX #29 MDN

Sources