One bilingual sentence, several valid character counts: a test notebook
This is a reproducible ToolDock test notebook, not a customer story. We used short synthetic strings to check our counter and explain disagreements between counting rules. The same string can satisfy a character limit and exceed a byte limit without either counter being broken.
Test 1: a bilingual sentence
你好，世界！ Hello world 👋Copy the line without a trailing newline, or choose Try mixed-language example in the tool. The expected counts are:
| Rule | Count | Reason |
|---|---|---|
| Han characters | 4 | 你、好、世、界; punctuation is separate. |
| Latin-script words | 2 | Hello and world. |
| Unicode code points | 20 | Includes three spaces, two punctuation marks and the wave emoji. |
| Without whitespace | 17 | The three spaces are excluded. |
| UTF-16 units | 21 | The wave uses a surrogate pair. |
| UTF-8 bytes | 35 | Han characters, full-width punctuation and emoji occupy multiple bytes. |
Set a limit of 20 and select Unicode code points: the sentence fits exactly. Change only the rule to UTF-8 bytes: it is 15 bytes over. That difference matters when a destination describes a limit loosely as “characters.” Ask for the actual rule instead of deleting text blindly.
Test 2: a family emoji
👨👩👧👦This test produces one grapheme cluster, seven code points, eleven UTF-16 units and twenty-five UTF-8 bytes. Four person emoji are joined by three zero-width joiners. Calling this simply “one character” is useful for visual editing but insufficient for storage validation. Rendering depends on the font and platform; grapheme segmentation is also tied to the browser’s Unicode implementation.
Test 3: two ways to write an accented letter
The precomposed letter é is one code point and two UTF-8 bytes. The sequence e followed by combining acute accent U+0301 is two code points and three UTF-8 bytes. Both are normally one grapheme cluster and one Latin-script word in this tool. We do not silently normalize your input, because changing its representation could change a signature, byte length or exact-match result.
How to use the results in a real task
- For a translation brief, establish whether punctuation and Latin words count toward the quota. Han-character count does not mean Chinese word count.
- For a web form, test a harmless short emoji string against its documented rule. A browser length constraint may use a different unit from the server.
- For a byte-limited field, choose UTF-8 bytes only when the destination actually uses UTF-8. This tool does not model another encoding or HTTP/JSON wrapper overhead.
- Copy the count report when discussing the issue. The report includes counts, not the original text.
Boundaries of this measurement
Han-script characters also occur in Japanese. This counter does not detect the language, segment Chinese words, or determine how a publisher charges for translation. Latin-script matching includes accented letters and internal hyphens or apostrophes, but is not a tokenizer for every language. Empty text returns zero. Non-empty line counts ignore whitespace-only lines. Punctuation, digits and whitespace have separate counts; they are not necessarily a complete partition of the text because symbols and marks exist too.
Grapheme counts require Intl.Segmenter. If it is unavailable, the tool explicitly reports that limitation. The reference behavior is documented in Intl.Segmenter; UTF-8 encoding uses TextEncoder. These links explain the APIs, not an endorsement of ToolDock. Check your destination’s own counting specification before submitting important work.
What changed after testing
We replaced the single generic output with separately labelled metrics, added a rule-selectable limit check and removed the old reading-time estimate. That estimate mixed English words and Han characters into one number without enough context. We retained local processing and do not save drafts. If you find a counterexample, send a synthetic reproduction through the suggestion form, including the browser and the counting rule you expected.