HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
christiangenco
wordlesolver
JavaScript2022–2022
christiangenco / wordlesolver

wordlesolver

Solver for the Wordle daily word puzzles

3Distinct people
3Mentions
0Explicit recommenders
7GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Solver for the Wordle daily word puzzles

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by 6-hour interval3 dated mentions

Observed mentions: 2022-01-09 18:59:21 UTC to 2022-01-15 16:49:32 UTC.

012022-01-09 18:00:00 UTC to 2022-01-10 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 9, 18:002022-01-10 00:00:00 UTC to 2022-01-10 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-10 06:00:00 UTC to 2022-01-10 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-10 12:00:00 UTC to 2022-01-10 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-10 18:00:00 UTC to 2022-01-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-11 00:00:00 UTC to 2022-01-11 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-11 06:00:00 UTC to 2022-01-11 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-11 12:00:00 UTC to 2022-01-11 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-11 18:00:00 UTC to 2022-01-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-12 00:00:00 UTC to 2022-01-12 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-12 06:00:00 UTC to 2022-01-12 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-12 12:00:00 UTC to 2022-01-12 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJan 12, 12:002022-01-12 18:00:00 UTC to 2022-01-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-13 00:00:00 UTC to 2022-01-13 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-13 06:00:00 UTC to 2022-01-13 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-13 12:00:00 UTC to 2022-01-13 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-13 18:00:00 UTC to 2022-01-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-14 00:00:00 UTC to 2022-01-14 06:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-14 06:00:00 UTC to 2022-01-14 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-14 12:00:00 UTC to 2022-01-14 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-14 18:00:00 UTC to 2022-01-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-15 00:00:00 UTC to 2022-01-15 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-15 06:00:00 UTC to 2022-01-15 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-15 12:00:00 UTC to 2022-01-15 18:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 15, 12:00

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jan 9, 18:002022-01-09 18:00:00 UTC2022-01-10 00:00:00 UTC101
Jan 10, 00:002022-01-10 00:00:00 UTC2022-01-10 06:00:00 UTC000
Jan 10, 06:002022-01-10 06:00:00 UTC2022-01-10 12:00:00 UTC000
Jan 10, 12:002022-01-10 12:00:00 UTC2022-01-10 18:00:00 UTC000
Jan 10, 18:002022-01-10 18:00:00 UTC2022-01-11 00:00:00 UTC000
Jan 11, 00:002022-01-11 00:00:00 UTC2022-01-11 06:00:00 UTC000
Jan 11, 06:002022-01-11 06:00:00 UTC2022-01-11 12:00:00 UTC000
Jan 11, 12:002022-01-11 12:00:00 UTC2022-01-11 18:00:00 UTC000
Jan 11, 18:002022-01-11 18:00:00 UTC2022-01-12 00:00:00 UTC000
Jan 12, 00:002022-01-12 00:00:00 UTC2022-01-12 06:00:00 UTC000
Jan 12, 06:002022-01-12 06:00:00 UTC2022-01-12 12:00:00 UTC000
Jan 12, 12:002022-01-12 12:00:00 UTC2022-01-12 18:00:00 UTC000
Jan 12, 18:002022-01-12 18:00:00 UTC2022-01-13 00:00:00 UTC000
Jan 13, 00:002022-01-13 00:00:00 UTC2022-01-13 06:00:00 UTC000
Jan 13, 06:002022-01-13 06:00:00 UTC2022-01-13 12:00:00 UTC000
Jan 13, 12:002022-01-13 12:00:00 UTC2022-01-13 18:00:00 UTC000
Jan 13, 18:002022-01-13 18:00:00 UTC2022-01-14 00:00:00 UTC000
Jan 14, 00:002022-01-14 00:00:00 UTC2022-01-14 06:00:00 UTC101
Jan 14, 06:002022-01-14 06:00:00 UTC2022-01-14 12:00:00 UTC000
Jan 14, 12:002022-01-14 12:00:00 UTC2022-01-14 18:00:00 UTC000
Jan 14, 18:002022-01-14 18:00:00 UTC2022-01-15 00:00:00 UTC000
Jan 15, 00:002022-01-15 00:00:00 UTC2022-01-15 06:00:00 UTC000
Jan 15, 06:002022-01-15 06:00:00 UTC2022-01-15 12:00:00 UTC000
Jan 15, 12:002022-01-15 12:00:00 UTC2022-01-15 18:00:00 UTC101

What Hacker News says

3 sources
Thanks for sharing your code. I had seen other people also mention that these 5 guesses (AESIR, ARISE, RAISE, REAIS, SERAI) all narrow down the list to 168 (in the worst case), but I was curious why the code I wrote to play with this was giving different answers. After reading your code, I see an error in it. In fact, only RAISE is optimal; the others are worse, and leave bigger lists (according to my code): RAISE: 168 … REAIS: 203 … AESIR: 220 ARISE: 220 … SERAI: 241 The error in your code is that your "evaluateGuess" function (right at the top, in the first 10 or so lines of https://github.com/christiangenco/wordlesolver/blob/9c3bd94a...): function evaluateGuess({ solution, guess }) { return [...guess].map((letter, index) => { return { letter, included: solution.incl
Read the rest
udes(letter), position: letter === solution[index], }; }); } is too simplistic, and not actually what the real game does. In the game, for each letter position, there are three possible responses: • Correct (Green), what you call "position" • Present (Yellow), what you call "included" • Absent (Grey) Here are three test cases, that you could try out on the real Wordle in recent days: • When the solution is "FAVOR" and our guess is "ERROR", Wordle's response is [Grey, Grey, Grey, Green, Green] — note that for the first two Rs in "ERROR", the correct response is Grey (Absent), because the last R has already "used up" the "Green" response. • When the solution is "FAVOR" and our guess is "ROARS", Wordle's response is [Yellow, Yellow, Yellow, Grey, Grey] — note that only the first R in "ROARS" gets a Yellow response and the second one gets Grey, because there's only one R in the solution. • (As pointed out by @pedrosorio in a sibling comment) When the solution is "ABBEY" and our guess is "APNEA", Wordle's response is [Green, Grey, Grey, Green, Grey], but your solver thinks that the second "A" would get a "Yellow" response too. You mentioned Donald Knuth's Mastermind paper; in fact in the paper (http://www.cs.uni.edu/~wallingf/teaching/cs3530/resources/kn...) Knuth points this out on the very first page: > Rule 2 is somewhat difficult to state precisely and unambiguously, and the manufacturers have in fact not succeeded in doing so on the directions they furnish with the game […] and gives an exact rule that you may want to study carefully. In my code, the `response` function I use (it's not the most efficient, but we can just memoize it) is: def response(h, g): ''' - The hidden word is h. - The guess is g. For each position in the word g, some color: - 'green' if in the same position - 'yellow' if present (after subtracting 'green's) - 'grey' if absent (after subtracting "green"s and "yellow"s) ''' assert len(h) == len(g) L = len(h) green = [i for i in range(L) if h[i] == g[i]] yellow = [] for i in range(L): # We want to check whether g[i] is "present" in h if i in green: continue for j in range(L): if j in green: continue if j in yellow: continue if h[j] == g[i]: yellow.append(i) break return (green, yellow) Note the three "continue" statements — they are crucial, to match the behaviour of the real Wordle (or Master Mind) on the three test cases I mentioned above.
In Best Wordle guessing strategy
I modeled my Wordle solver[1] after Donald Knuth's Mastermind strategy[2]. An optimal guess is found by looking at the list of possible solutions and for each of those possible solutions checking how much each possible guess would narrow down the list of possible solutions. Once you have a list of all possible guesses and how much each of those possible guesses would narrow down the total number of possible solutions for each possible solution, sort them by the maximum number of total remaining guesses. The optimal first guesses from my solver are ARISE, RAISE, AESIR, REAIS, or SERAI because each will narrow down the possible word list to at minimum 168 remaining words. Each guess after that uses the same algorithm with the list of possible guesses filtered with the information you learned in previous guesses. edit: formatting 1. https://
Read the rest
In Best Wordle guessing strategy

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.