Analyzers Tools
Analyze and measure text and data. Get insights about your content.
Analysis tools that turn raw input into useful signals - counting characters and words, parsing logs, and breaking down the data you paste in.
1 tool availableWhat a character count is actually counting
The Character Counter answers four questions at once, and only one of them is the question a field validator usually means. A rule that says "50 characters" can be enforced against code points, UTF-16 code units, or the user-perceived characters that Unicode calls grapheme clusters - and those three numbers disagree exactly where the bugs live. UAX #29, the standard that defines text segmentation, describes grapheme clusters as "user-perceived characters", alongside words and sentences.
| Unit | Who counts this way | Where the numbers diverge |
|---|---|---|
| Code point | Unicode scalar values; most server-side char_length() functions | the unit a backend length check usually means |
| UTF-16 code unit | JavaScript String.length, Java String, most native form widgets | one emoji or other astral character counts as two |
| Grapheme cluster | readers, and the UAX #29 default boundary rules | a combining mark, or an emoji join sequence, counts as one |
| Word and sentence | the UAX #29 word and sentence boundary rules | abbreviations, hyphenated compounds and URLs split per rule set |
Three fixtures that expose the difference
Paste three versions of the same name into the counter and the divergence fits on one screen: the composed form, the decomposed form written as a letter followed by a combining mark, and an emoji family sequence. UAX #29 rule GB11 exists for exactly this case - "Do not break within emoji modifier sequences or emoji zwj sequences" - so the emoji sequence counts as one user-perceived character even though its code-point count is far higher.
That is why a boundary test on a text field should carry at least three fixtures: the composed character, the decomposed character, and one emoji sequence. Then assert the same limit at every layer that enforces it - the form, the API validator and the database column - because a rule that is correct in the browser can still truncate in a column typed for code points. The Character Counter gives you the reference numbers to write those assertions from, and the test-data guide covers building boundary fixtures that survive the trip through a fixture pipeline, while the test case guide shows where boundary cases belong in a suite.
A byte count and a character count answer different questions
RFC 3629 makes the gap explicit: "UTF-8 encodes UCS characters as a varying number of octets, where the number of octets, and the value of each, depend on the integer value assigned to the character in ISO/IEC 10646". An ASCII character costs one octet; a Latin-1 accented letter costs two; most CJK characters cost three. So a column typed for 50 bytes holds 50 ASCII characters and roughly 16 Chinese ones, and a validator that counts characters while the database counts bytes will accept input the column then truncates. Assert both numbers at every layer that enforces the limit.
Two strings that look identical can be different strings
Unicode separates what renders the same from what is stored the same. UAX #15 defines the first case as "canonical equivalence", a "fundamental equivalency between characters or sequences of characters which represent the same abstract character", and then gives two ways to write it: NFC is "Canonical Decomposition, followed by Canonical Composition". The letter e with an acute accent therefore exists as one code point and as two, and both display identically. An equality assertion written on the raw bytes fails on a duplicate that looks the same, while a unique index on the raw string happily accepts both. Normalise to NFC at the boundary, then compare, count and index.
Both rules belong in the fixture set, not just in the tool: the Character Counter gives the reference numbers, the validators hub has the field-level checks, and the test-data guide covers building fixtures that survive a pipeline.
Source: UAX #29: Unicode Text Segmentation - grapheme cluster, word and sentence boundary rules; rule GB11; RFC 3629, UTF-8, a transformation format of ISO 10646; UAX #15: Unicode Normalization Forms.