Character Counter

Input

38 graphemes38 code points38 bytes

Live result

38Characters

7Words

2Lines

38Code points

38UTF-8 bytes

Good fit

Use this tool when

You are checking text against a field character limit.
You want words and lines in addition to characters.
You need to know which length model a platform counts.

Keep the original

Avoid it when

You only need the raw byte size.
You need per-character diagnostics instead of totals.
The destination documents a counting model you can match directly.

Reviewed truth vectors

Examples that expose the edge cases

InputThe quick brown fox.

Output20 characters · 4 words · 1 line

Characters count user-perceived graphemes.

Input

Line 1
Line 2

Output13 characters · 4 words · 2 lines

Line breaks are counted as lines.

Inputcafé 😀

Output6 characters · 2 words

An emoji counts as one character but more bytes.

Transparent implementation

How it works

01
Segment user-perceived characters with Intl.Segmenter.
02
Split on whitespace for words and on line breaks for lines.
03
Report code points and UTF-8 bytes for comparison.

Known limitations

What the result cannot promise

Word counting splits on whitespace and may differ from editorial rules.

A platform may document characters without defining its model.

Counts exclude transport and escaping overhead.

Questions before copying

Frequently asked questions

Which number matches a platform limit?

It depends on the platform. Many count code points or graphemes; compare the models shown here against the field's documented rule.

How are emoji counted?

A single emoji is one character (grapheme) but can be several code points and bytes, all shown separately.

How are words counted?

Words are runs of non-whitespace separated by spaces or line breaks.

Experience, expertise & trust

How we verify this tool

GlyphSift Editorial — Text-engine authors & reviewers

The GlyphSift Editorial team designs the deterministic text engine, writes each tool's examples against real Unicode edge cases, and reviews every claim before a page becomes eligible for indexing. We build and test the software we document; we do not outsource the copy to generic content mills.

Each tool page is reviewed against the same six input classes the engine is tested with — ASCII, emoji, combining marks, non-Latin scripts, empty input, and 5,000-grapheme input — and cannot become eligible if it is only a parameter variation of another page.

Automated evidence

Tool-contract & coverage suite30 deterministic cases
tests/tools-30.test.mjs mirrors the ToolRunner dispatch and asserts every registered engineId returns the contracted output shape, plus a coverage guard so no tool silently drops characters.
Run in: node --test after a production build (vinext build)
Rendered-HTML suite12 deterministic cases
tests/rendered-html.test.mjs renders the deployed server bundle and asserts the Unicode-version manifest and each wave's tool markup are present in the server-rendered HTML.
Run in: node --test against the built dist/server bundle
Unicode inspection suite11 deterministic cases
tests/unicode-inspection.test.mjs verifies grapheme/code-point/byte counting and hidden-control detection using explicit \u escapes for combining and bidirectional characters.
Run in: node --test against the runtime's Unicode data
Compatibility risk suite13 deterministic cases
tests/compatibility.test.mjs checks that bidirectional controls, invisible characters, mixed scripts, and NFKC-changing input raise the documented risk status, and that safe-text stripping preserves ordinary content.
Run in: node --test, deterministic analyzer

Standards this tool follows

UTS #39: Unicode Security Mechanisms
Confusable and mixed-script detection methodology.
UAX #9: Unicode Bidirectional Algorithm
Bidirectional control characters flagged during inspection.
UAX #15: Unicode Normalization Forms
NFC/NFKC normalization comparisons.
RFC 3629: UTF-8
Byte-length counting for the UTF-8 encoding.