Four units, one word

1. Code units — what JavaScript's .length counts (UTF-16). "👨‍👩‍👧‍👦".length === 11.
2. Code points — Unicode scalar values. The family emoji is 7.
3. Grapheme clusters — what a human sees. The family emoji is 1. A flag is 1. é built from e + combining acute is 1.
4. Weighted units — what X counts. URLs are 23, some ranges weigh 2.

A counter is only "right" relative to the unit your destination uses. Mismatch the unit and you get the classic failures: a form that rejects text that fits, or accepts text the platform then truncates.

Graphemes: the only unit readers care about

ZWJ sequences, regional indicators, combining marks, emoji modifiers — all of these assemble multiple code points into one visible glyph. The browser-native way to count them:

const segmenter = new Intl.Segmenter("en", { granularity: "grapheme" });
const graphemes = [...segmenter.segment(text)].length;

Any serious counter should default to graphemes. Code-unit counts are an implementation detail leaking into UX.

X: the weighted regime

X (Twitter) allows 280 weighted characters per standard post. The twitter-text configuration assigns weights per range: most characters weigh 1, URLs are a flat 23 regardless of actual length, and emoji/wide ranges weigh 2. A 193-character draft with a 47-character link and one emoji lands around 169 weighted — the link collapses, the emoji doubles. If your validation uses a plain count, it is validating against a limit that does not exist.

SMS: the segment regime

SMS billing counts segments, sized by encoding: GSM-7 gives 160 characters per single message (153 when concatenated); UCS-2 — triggered by a single emoji or CJK character — drops that to 70 (67 concatenated). The GSM-7 extension table (€ ^ { } \ [ ] ~ |) costs two units per character. One emoji does not just add a character; it re-encodes the entire message and more than halves its capacity.

The tool

Disclosure: I built toolkitloop.com/character-counter, one of 30 free browser tools I maintain. It counts graphemes by default, has an X mode applying the weighted URL rule, reports with/without spaces, and runs entirely client-side — your draft never leaves the browser. A companion social media character limits guide keeps the per-field numbers in one place.

The broader lesson: whenever you build around a "character limit," find out which of the four units the destination counts — then count that. Everything else is a guess wearing a number's clothes.

Most wheel implementations pick like this:

segments[Math.floor(Math.random() * segments.length)]

For a yes/no decision wheel this is fine. Math.random() is deterministic and theoretically predictable, but nobody is attacking your lunch decision. The problem starts when the wheel picks giveaway winners, assigns on-call rotations, or does anything where someone can lose something. Then "almost uniform" stops being good enough, and modulo bias — the slight unevenness of Math.floor(Math.random() * n) for certain n — becomes a real, if small, unfairness.

Rejection sampling in 15 lines

The Web Crypto API exposes OS-level entropy via crypto.getRandomValues(). Turning random 32-bit integers into a uniform index in [0, n) without modulo bias is a textbook rejection sample:

function fairIndex(n) {
  const max = 0xffffffff;
  const limit = max - (max % n); // reject the biased tail
  const buf = new Uint32Array(1);
  let x;
  do {
    crypto.getRandomValues(buf);
    x = buf[0];
  } while (x >= limit);
  return x % n;
}

Values at or above limit would map unevenly onto the segments, so we throw them away and draw again. The expected retry count is ~1.0 — the loop is practically free, and the distribution is exactly uniform.

Architecture: selection before animation

Clean wheel code separates the two halves completely:

1. Select the winning index with fairIndex() — pure function, unit-testable.
2. Derive the final rotation angle from the index (a few full turns for drama, then land mid-slice).
3. Animate to that angle with CSS transitions.

Because selection is decoupled, you can verify fairness offline: run 100,000 draws, histogram the results, and confirm uniformity before any pixel moves. If you're building any picker — wheels, lotteries, shuffles — this test is cheap and catches real bugs (off-by-one slices, rounding in angle math, you name it).

Seedless, serverless, stateless

The whole pipeline runs client-side. There's no seed to protect, no server to trust, and — relevant if your wheel handles entrant names — nothing uploaded anywhere. For a small giveaway tool, "we never see your list" is the simplest privacy policy there is.

Disclosure

I built a free wheel implementing exactly this at toolkitloop.com/yes-no-wheel — yes/no mode plus custom segments, no signup. It's one of 30 client-side tools I maintain at ToolkitLoop. The patterns above are general; adapt them freely.

If you've ever audited randomness in a picker, shuffler, or A/B splitter — what did you find? The subtle bugs are always more interesting than the obvious ones.