Character / grapheme / word count
Local statistics: Unicode code points, graphemes (Intl.Segmenter), UTF-16 units, UTF-8 bytes, lines / blank lines, English words, CJK characters and EOL style. Chinese is never faked as space-delimited words.
Inputs and parameters
input— Input textsteps— Optional steps before counting (comma-separated; blank = count directly)normalize— Unicode normalisation before countingreportLang— Report languageincludeBom— Include UTF-8 BOM on report download
Real example
Hello 中文 world → English report
→ Unicode code points: 14 · Graphemes: 14 · UTF-16 code units: 14 · UTF-8 bytes: 18
Lines: 1 · Non-empty lines: 1 · Blank lines: 0
English words: 2 · CJK characters: 2 · Whitespace-separated fragments (NOT Chinese word count): 3
Line ending: LF · Trailing newline: noLimits and failure handling
English words are Latin-letter runs (with simple hyphen/apostrophe handling), not full NLP tokenisation; no Chinese/Japanese word count is provided. Grapheme counts depend on Intl.Segmenter and fall back to code points with an explicit label when unavailable. Whitespace fragments are indicative only. The report is plain text, copyable/downloadable (UTF-8, same BOM policy). Limits 2 MiB / 100 000 lines; cancellable.
FAQ
Code points vs graphemes vs UTF-16 units?
Code points are Unicode scalars via Array.from; graphemes are what a reader perceives as one character (e+acute or a ZWJ family emoji = 1); UTF-16 units are JS string .length (an emoji often counts as 2+). All three are reported separately.
Why is there no Chinese word count?
Chinese is not space-segmented: space-splitting yields fragments, not words. This site explicitly labels "Whitespace-separated fragments (NOT Chinese word count)" and reports CJK character count instead; use a dedicated segmenter for real word counts.
Can I clean the text before counting?
Yes. Put trim-lines,deduplicate etc. in "Optional steps before counting"; statistics then describe the transformed text in that order. Leave it blank to count the raw input.