Building a Wordle Solver: Letter Frequency Analysis in JavaScript

Alamzeb Khan — Tue, 06 Oct 2026 20:44:59 +0000

Wordle looks simple. Five letters, six guesses. But building a good solver — one that consistently cracks the puzzle in 3-4 guesses — is a genuinely interesting algorithms problem. Here's how I approached it when building the Wordle Solver on WordyLab, my free word game toolkit.

The Problem

Given a set of constraints (green = correct letter + position, yellow = correct letter wrong position, gray = letter not in word), narrow 12,000+ possible words down to the answer in as few guesses as possible.

Step 1: Letter Frequency Scoring

function scoreWord(word, frequencyMap) {
  const uniqueLetters = new Set(word);
  let score = 0;
  for (const letter of uniqueLetters) {
    score += frequencyMap[letter] || 0;
  }
  return score;
}

Note the Set — we count each letter once per word. A word like "speed" shouldn't get double credit for the double-e; what matters is coverage of the alphabet.

Step 2: The Optimal Opening Guess

Run frequency analysis on the full word list and the best openers surface: words with five unique, high-frequency letters. Classics like "adieu," "audio," and "raise" all score well because they test the most common vowels and consonants simultaneously.

Step 3: Constraint Propagation

After each guess, filter ruthlessly — greens must match exact position, yellows must be present but elsewhere, grays must be absent. The gray-letter edge case is where most DIY solvers break: if you guess "speed" and the first E is green but the second E is gray, the E is in the word, just once. Your filter has to handle letter counts, not just presence.

Step 4: Entropy (The Real Secret)

Frequency scoring gets you to 4-5 guesses. To hit 3 consistently, you need information theory. The optimal guess isn't the most likely answer — it's the guess that eliminates the most candidates regardless of the outcome. For each candidate guess, simulate every possible feedback pattern and pick the one with minimum expected remaining pool.

Beyond Wordle

The same toolkit powers anagram solvers, Scrabble word finders, and crossword solvers. All client-side, all instant. Try the working solver at wordylab.com — free, no signup.

I Built a Free Word Counter That Runs 100% in Your Browser — Here's What I Learned About Client-Side Text Analysis

Alamzeb Khan — Tue, 06 Oct 2026 20:43:54 +0000

Counting words sounds trivial. It's not.

When I set out to build Word Counter Suite — a free toolkit with 15+ text analysis tools — I assumed the word counting part would take an afternoon. It took weeks. Here's why, and what I learned about doing real text analysis entirely client-side.

The Naive Approach (and Why It Breaks)

Most tutorials tell you this:

const wordCount = text.trim().split(/\s+/).length;

This breaks in at least five ways:

Hyphenated words — is "state-of-the-art" one word or four? Microsoft Word says one. Google Docs says one. Your regex says four.
Em dashes and en dashes — "word—another" with no spaces. One word or two?
Numbers — "3.14" contains a period. Is it a sentence boundary?
URLs and emails — "user@example.com" has no spaces but isn't a normal word.
Unicode — \s doesn't catch all Unicode whitespace. Neither does \w handle all word characters.

What Production Tools Actually Do

Real word counters (Word, Google Docs, professional tools) follow published segmentation rules. The closest public standard is Unicode Text Segmentation (UAX #29), which defines word boundaries across languages.

I ended up implementing a rule-based tokenizer that handles apostrophes within words, hyphens within compounds, decimal numbers, URLs and emails as single tokens, CJK characters, and emoji sequences.

function tokenize(text) {
  const normalized = text.normalize('NFC');
  const wordPattern = /[\p{L}\p{N}]+(?:[''\-‑–][\p{L}\p{N}]+)*/gu;
  return normalized.match(wordPattern) || [];
}

The \p{L} and \p{N} Unicode property escapes do the heavy lifting — they match letters and numbers in any script, not just ASCII.

Why Client-Side Matters

Every tool on Word Counter Suite runs entirely in the browser. No server round-trips, no data leaving the machine. Web Workers handle heavy analysis off the main thread, so pasting a 100,000-word manuscript doesn't freeze the UI. No backend means zero infrastructure cost and infinite scale.

Beyond Word Count

Once you have a tokenizer, the rest follows: reading time (words ÷ WPM), keyword density (token frequency with stop-word filtering), speaking time, and readability scores like Flesch-Kincaid.

Try It and Break It

The toolkit is free at wordcountersuite.com — no signup. If you find text that breaks the counter, I'd genuinely love to know. Edge cases in Unicode text segmentation are endless, and every weird input makes the tokenizer better.

DEV Community: Alamzeb Khan