Count sentences in plain text with the browser's locale-sensitive segmenter when available, with a more limited punctuation fallback for older browsers.
Last updated: August 2026 | By Workshelve Team
Sentences
0
Words
0
Graphemes
0
Modern browsers can segment sentences, words, and graphemes with Intl.Segmenter, but that uses the browser locale rather than auto-detecting the language of your pasted text.
This tool estimates sentence boundaries. It is useful for drafts and editing targets, but it is not a grammar engine and does not decide whether a fragment is a complete sentence in the linguistic sense.
Older browsers fall back to punctuation-based sentence splitting, which can over-count abbreviations like Dr. and still miss difficult language-specific or quotation edge cases.
The primary count is a sentence-boundary estimate. When available, the tool usesIntl.Segmenter with sentence granularity. That follows the browser's locale-sensitive segmentation rules, which is better than splitting only on periods, question marks, and exclamation points.
Even then, the result is still segmentation rather than grammatical analysis. The tool identifies likely sentence boundaries, but it does not judge whether a fragment is a complete sentence in the formal linguistic sense.
The companion stats use the same principle. Word count uses word segmentation when available. Grapheme count uses grapheme segmentation when supported; older browsers fall back to Unicode code-point counting and label that fallback explicitly.
Sentence count uses Intl.Segmenter(undefined, { granularity: 'sentence' }) when supported. Word count uses granularity: 'word' with isWordLike, and grapheme count uses granularity: 'grapheme'.
Older browsers fall back to punctuation-based sentence splitting. That fallback recognizes `.`, `!`, `?`, `ใ`, `๏ผ`, `๏ผ`, and `ุ` even when no space follows the punctuation, but it is still only a rough estimate and can split abbreviations or miss more complex sentence boundaries. Word counting also falls back to whitespace-delimited tokens, which is not reliable for languages that do not normally separate words with spaces.
Different browsers and environments can ship different segmentation data. Two valid implementations may occasionally disagree on difficult edge cases, especially with mixed-language text, abbreviations, quotations, and fragments without terminal punctuation.
Example 1: Abbreviation edge case
This shows why punctuation-only logic is weaker. It can incorrectly treat the abbreviation Dr. as a full sentence boundary.
Example 2: Grapheme vs UTF-16 length
The old label Characters was misleading because JavaScript string length counts UTF-16 code units, not user-perceived characters. When Intl.Segmenter is available, the tool reports grapheme clusters; older browsers fall back to Unicode code points and label them accordingly.
No. When Intl.Segmenter is available, it uses the browser runtime locale configuration rather than detecting the language of the pasted text itself.
Sentence boundaries are messy. Abbreviations, quotes, headings, ellipses, fragments, and mixed-language punctuation can all make segmentation ambiguous.
Because JavaScript string length counts UTF-16 code units, which can over-count emoji and composed character sequences. With Intl.Segmenter, the tool reports grapheme clusters; older browsers instead report Unicode code points and label them that way.
No. The fallback is only a punctuation-based estimate for older browsers. It is useful as a backup, but it can over-split abbreviations and miss harder language-specific cases.
They may ship different locale data or segmentation behavior. That can produce small differences on difficult sentence-boundary cases.
No. It estimates sentence boundaries and word boundaries, plus grapheme clusters when Intl.Segmenter is available. Older browsers use weaker fallbacks, and the tool does not grade grammar or meaning.