Word count vs character count: which one should constrain your copy?
Short answer
Constrain by characters when a fixed space has to hold the text — buttons, table cells, meta titles, SMS, database columns. Constrain by words when the reading experience matters more than the box — body paragraphs, blog intros, briefs written for a writer. Characters predict whether text fits; words predict how long it takes to read.
Both counts describe the same string, but they answer different questions. A character count answers "will this fit in the space I drew?". A word count answers "how much is there to read?". Picking the wrong one is how a design ends up with a label that satisfies its brief and still wraps onto a second line.
Characters describe fit
Space is consumed by glyphs, not by words. "Internationalisation settings" is two words and 29 characters; "Set up how we bill you" is six words and 22. The two-word string is the one that breaks the button. Anywhere a container has a fixed width — buttons, chips, table columns, tab labels, meta titles, database fields — the character count is the number that maps onto the constraint.
Characters are also the safer unit for testing extremes. If you want to know whether a card survives its worst realistic input, generate copy at the maximum character count the field allows rather than at an average word count.
- Words
- 7
- Characters
- 40
- No spaces
- 34
- Chars per word
- 4.9
Change one long word for two short ones: the word count moves, the character count barely does — and only one of those two numbers predicts whether the string still fits.
Words describe reading
When there is no hard boundary — a blog introduction, a product description, an onboarding paragraph — the question changes from "does it fit" to "is it the right amount to read". Words map to that far more directly, which is also why briefs, editorial guidelines and content models are written in words. A writer can hit "120 to 150 words". Nobody drafts to a character budget by hand.
Which to use, by context
| Context | Real constraint | Count by | Why |
|---|---|---|---|
| Button label | Fixed component width | Characters | A three-word label of long words breaks a button that a five-word label of short words survives. |
| Meta title | Truncation in search results | Characters | Truncation is by rendered width, so characters approximate it far better than words. |
| Table cell | Column width | Characters | The column does not care how many words are in the string. |
| SMS or push | Hard platform limit | Characters | The limit itself is expressed in characters. |
| Blog intro | Reading experience | Words | Reading time and rhythm scale with words, not characters. |
| Copy brief | Writer instruction | Words | "About 150 words" is a target a writer can work to; "900 characters" is not. |
| Card body | Both | Characters, then check words | The box sets the hard limit; the word count tells you whether it still reads like a sentence. |
Where the two counts disagree
Counting rules are only useful if they are stated. TypeMatch treats a word as a run of characters separated by whitespace, so a hyphenated compound counts once and an em dash surrounded by spaces does not count at all. Characters are counted by grapheme cluster: one visible emoji is one character, and an accented letter composed from two code points is still one. Backend limits are often measured in bytes or UTF-16 units instead, which is why an emoji that looks like one character can consume four of a database field's allowance.
Spaces are the other common disagreement. TypeMatch reports characters with and without spaces separately, because some limits include them and some do not, and guessing costs you a whole round of revisions.
Applying it
In practice: set a character target when a box exists, set a word target when a reader does, and when a component has both — a card with a fixed height and a paragraph inside it — constrain by characters and sanity-check the word count afterwards.
You can try either target directly with the exact character count generator or the exact word count generator, and see the ranges we design around in the UI copy template library.
Frequently asked questions
Do spaces count as characters?
+
It depends on the system you are designing for. Search engines and most CMS fields count spaces; some legacy database limits and a few word processors report a separate count without them. TypeMatch shows both, so you can target whichever rule your constraint actually uses.
How are emoji counted?
+
TypeMatch counts by grapheme cluster, so a single visible emoji counts as one character even when it is stored as several code units. That matches what a person sees in a design, but it can differ from a backend limit measured in bytes or UTF-16 units.
Which count does a meta title limit use?
+
Search result truncation is driven by rendered pixel width rather than a fixed count, so a character target is only an approximation. It is still the more useful of the two, because a word target says nothing about how wide those words are.
About this guide
The TypeMatch team · Product and design, TypeMatch
Written and maintained by the people who build TypeMatch. Corrections are welcome.
Last updated