Skip to main content
{/}codefunc
GuidesAugust 6, 2026 · 6 min read

Word and Character Counts for UI Copy, SEO, and Reviews

How to count words and characters the way products and platforms do — limits, diffs, Markdown pitfalls, and a practical editing workflow for developers who ship copy.

By codefunc

word-countcharacter-countcopywritingseomarkdowntext-diff

Character limits are product constraints as much as writing advice. Meta titles truncate in SERPs, tweets and Discord embeds cut mid-sentence, SMS segments bill per length, and form validators reject strings that looked fine in Figma. Developers who treat copy as "just strings" discover counting rules only after QA files a bug. A reliable count — and a clear diff when copy changes — saves rounds of back-and-forth with design and marketing.

Bottom line: Know whether your limit is characters, graphemes, or bytes; count in the same way the platform validates; and verify edits with a diff. Use a Word & Character Counter, Text Diff, and Markdown Preview in the browser so draft copy never needs to leave your machine.

Who this guide is for

Frontend engineers, technical writers, and PMs who enforce length limits in UI, generate meta tags, or review PR copy. If you have ever wondered why length in JavaScript disagreed with a designer's Google Doc count, this guide explains the gap.

Words vs characters vs bytes

Metric What it measures Where it matters
Words Tokens split on whitespace (locale-dependent) Essays, docs, reading-time estimates
Characters (all) Every code unit / character including spaces Many "character limit" UIs
Characters (no spaces) Letters and punctuation only Some academic or contest rules
Graphemes User-perceived characters (emoji, accents) True UX length for display
UTF-8 bytes Storage and some SMS / binary protocols Databases, Twilio segment math

JavaScript "e\u0301".length is 2 (base letter + combining acute), while users see one grapheme (é). Many emoji are also multiple UTF-16 code units. If your validator uses string.length, you are not always counting what humans see. For emoji-heavy or accented input, use a grapheme splitter or Intl.Segmenter where available.

Platform limits you will hit

Approximate ceilings change; always verify against current docs. Patterns stay stable:

Surface Typical constraint Count type
HTML title / SERP display ~50–60 characters visible Characters (display)
Meta description ~150–160 characters visible Characters
Open Graph titles Truncation varies by network Characters
SMS (GSM) 160 chars per segment Septets / encoding-dependent
SMS (UCS-2) 70 chars per segment When non-GSM characters appear
Many App Store subtitles Hard character max Characters
Database VARCHAR(n) n characters or bytes by collation Check DB docs

Ship validators that match the backend rule, and show the same count in the UI. Dual sources of truth (maxLength on an input vs Zod schema vs DB) are a classic off-by-one factory.

Counting UI copy the useful way

For product strings:

  1. Count with spaces unless the platform says otherwise.
  2. Include punctuation — limits rarely exclude it.
  3. Decide whether newlines count (they usually do).
  4. Test CJK text: "word" counts are a poor fit; prefer characters.
  5. Test one string with emoji and combining marks.

Paste into a Word & Character Counter during review, then lock the limit in code. Do not rely on eyeballing against a screenshot of a SERP.

Reading time and docs

Word counts feed "N min read" labels. Pick a fixed WPM assumption (often 200–250 for UI copy pages), document it, and compute from words — not characters. Changing the counter definition later shifts every badge.

Markdown and "hidden" characters

Markdown sources fool raw counts:

  • Syntax (**, #, []()) inflates characters if you count the source
  • Rendered text is what users read and what many CMS limits apply to
  • Code blocks dominate word counts without adding prose value
  • HTML entities in source (&) are multiple characters before decode

Workflow:

  1. Draft in Markdown.
  2. Preview with Markdown Preview to see rendered structure.
  3. Count the rendered plain text for user-facing limits, or count source if the limit is on the CMS field as stored.
  4. Know which of those two your CMS enforces.

Editing with diffs, not vibes

When legal or marketing returns a revised paragraph, do not re-read the whole page hoping to spot changes. Paste old and new into Text Diff:

  • Confirm only intended phrases changed
  • Catch accidental deletions of product names or URLs
  • Verify the new version still fits the character budget

Diff-first review is especially useful in PRs where copy lives next to code — reviewers can approve string changes with the same rigor as logic changes.

Microcopy patterns that stay short

Length problems often mean the sentence is doing too many jobs. Patterns that help:

  • Lead with the verb in buttons: "Save" not "Click here to save your changes"
  • One idea per tooltip
  • Prefer specifics over hedging ("Export CSV" vs "You may export your data")
  • Move explanations to docs when a label exceeds ~40 characters

Counting without rewriting just reports the fire. Use the number to justify a cut.

i18n: English is the easy mode

German, Finnish, and French UI strings often grow 20–40% versus English. If you only count English:

  • Buttons overflow
  • Table headers wrap awkwardly
  • Push notifications truncate mid-word

Budget slack in the layout (or use flexible containers) and run character counts on localized strings before release. Word counters that assume space-separated words undercount languages without spaces.

Privacy for draft copy

Unreleased product names, pricing, and legal drafts should not go to random online counters. Prefer client-side tools: paste, count, diff, preview — with no upload of the text to codefunc servers. Clear the tab on shared machines when the copy is sensitive.

A practical review checklist

  • Limit type agreed (chars vs bytes vs graphemes)
  • UI counter matches server validation
  • Edge cases tested: emoji, CJK, newlines
  • Markdown counted as stored vs as rendered (intentionally)
  • Revisions verified with a text diff
  • Localized strings re-checked for overflow

Use these codefunc tools alongside this guide:

Practical takeaway

Treat counting rules as part of the API contract for strings. Align UI, validator, and database definitions; remember JavaScript length is not always what users see; and separate Markdown source counts from rendered text counts. When copy changes, diff it. For everyday work, keep drafts local with Word & Character Counter, Text Diff, and Markdown Preview — no data needs to leave your machine.

Sources

Try it on codefunc

Related articles

3

Search tools

Find a developer tool