Methodology

The word list, the index, and where this stops

Everything this site does is a statement about one file. This page says which file, where it came from, what was done to it, and — at greater length than the claims, deliberately — the questions it cannot answer.

Word listENABLE1 · public domain Words172,820 Indexed168,548 · 2–15 letters Anagram keys152,215 Index shards14 · 3,204,287 bytes

What is measured, how it is kept, and what it cannot tell you

What is measured. Set membership, and nothing else. Given a multiset of letters, the site reports every entry of a named word list that can be spelled from it, using each letter no more often than it was supplied. There is no ranking, no scoring, no frequency model and no judgement about which answers are worth playing. A word is in the list or it is not, and everything shown is in the list.

How it is kept. The list is a file in this site's own directory, served as plain text, with a provenance note beside it recording its source, its SHA-256 and the single normalisation applied to it. At build time an authoring tool converts it into an anagram-key index — each word's letters sorted, mapped to every word sharing them — split into one file per word length so that a query downloads only the lengths it can reach. The index is generated, never hand-edited, and the suite regenerates it and compares byte for byte.

What it cannot tell you. Whether a word will be accepted by the game in front of you, because that depends on a proprietary word list this site does not use. Whether a word is worth playing, because nothing here sees the board. And anything about words outside ENABLE1 — proper nouns, hyphenations, most recent coinages, and the 4,272 entries of sixteen letters or more, which are in the file but outside the index because no fifteen-character rack can reach them.

The word list

ENABLE1 — the Enhanced North American Benchmark Lexicon — was researched and compiled by M. Leo Cooper and Alan Beale and released into the public domain. It holds 172,820 entries, every one of them lowercase letters only: no proper nouns, no hyphens, no apostrophes, no diacritics. It was chosen because it is genuinely free to redistribute, because it is large enough to be useful, and because it can be shipped to a visitor's browser without anyone's permission being in question.

The exact copy this site serves is wordlist/enable1.txt, and its full provenance — the mirror it was fetched from, both SHA-256 hashes, the one appended newline that is the only modification, and the measured disagreement between circulating mirrors — is recorded in wordlist/PROVENANCE.md. Both are served rather than described, because a word site that will not show you its word list is asking to be taken at its word.

The official tournament lists are a different matter and a permanent one. TWL and NWL in North America, and Collins elsewhere, are proprietary compilations. They are not used here, are not shipped here, and will not be added later; there is no version of this site that ranks better by redistributing somebody's licensed database. That is also why the results here will sometimes disagree with a game's own judge, and why this site tells you the name of what it checked instead of implying an authority it does not have.

One thing that follows and is worth saying plainly: Word Sieve is an independent tool with no affiliation to, endorsement from, or connection with any word game or its publisher. Where a game is named anywhere on this site, it is named only to answer the question a visitor actually asked.

The index

Every anagram of a word has the same letters, so sorting a word's letters produces a key shared by exactly its anagrams. aelpp is the key for appel, apple and pepla. Build that map once and the question "what can I make from these letters?" stops being a search over words and becomes a handful of lookups.

index = { sorted(word) → [every word with those letters] }

Why it is split by length

The whole index is 3,204,287 bytes across 152,215 keys, which is more than any single query needs. It is written as fourteen files, shard-02.txt through shard-15.txt, one per word length, and a rack fetches only the lengths it could possibly reach. A five-letter rack pulls shards 2 through 5 — about 127 KB — and a seven-letter rack pulls 2 through 7, about 645 KB. Cloudflare serves them compressed, which in practice is roughly a third of those figures. Whatever your rack actually pulled is printed under your results in bytes.

They are fetched after the page has loaded and they are data rather than code, which is why they are not counted in the page's weight — every page on this site stays under the 100 KB pre-advertising ceiling the portfolio holds itself to, and the index is disclosed separately rather than hidden inside that number or excluded from it quietly.

Two search paths, and one of them is a scan

Without a blank, the solver enumerates the distinct letter-combinations of your rack and looks each one up. A seven-letter rack has at most 120 combinations of two letters or more, so the work is about 120 map lookups rather than 172,820 comparisons — three orders of magnitude, and the reason the answer is instant.

With a blank it does something different, and this page would rather say so than keep the tidier claim. A blank stands for any letter, so answering by lookup would mean generating every substituted key: 26 per combination for one blank, 351 for two, which on a long rack is millions of lookups. Instead the solver walks the keys of the shards it has loaded and keeps every key whose letters exceed the rack by no more than the number of blanks. That is a scan. It is bounded by keys rather than by words — tens of thousands, not hundreds of thousands — and it is fast for the same reason, but calling it a lookup would be untrue, so it is not called one.

Because there are two paths, there are two chances to be wrong. The test suite runs the scan path on racks that contain no blanks and requires it to return exactly what the lookup path returns; separately, an authoring-tool check drives this site's real solver against a brute-force scan of all 172,820 words and fails if a single word is missing or invented, including on a rack planted to make them disagree.

Where this stops

The word list is a snapshot of somebody else's judgement

ENABLE1 was compiled decades ago by people making editorial decisions about what counts as a word. This site does not curate it, add to it, or quietly patch entries that look wrong; if a word is missing or strange, that is a fact about ENABLE1, and the honest response is to name the list rather than to start maintaining a private fork nobody can check. The list will therefore lag current usage, and it always will.

It is not the judge of your game

A word found here may be refused by a game judging against a tournament list, and a word your game accepts may simply not be in ENABLE1. Neither is a defect here. There is no way to close that gap without redistributing a proprietary list, so the gap is disclosed instead of narrowed.

Nothing here knows the board

The solver sees letters. It does not see what is already played, which squares are open, what your opponent is holding, or what any of it is worth. It answers a question about a dictionary, not a question about a game.

The fifteen-character cap is a real edge

Racks are capped at fifteen characters because that is the longest indexed word. It is stated on the page and refused by name rather than silently truncated — a solver that quietly drops your sixteenth letter and then reports a complete-looking answer is worse than one that says no.

A blank is limited to two, and that is a product decision

The scan path is exact for any number of blanks; the limit of two exists because two is how many blank tiles a rack carries in the games people bring here, and because three blanks on a long rack returns tens of thousands of words, which is a list rather than an answer. The refusal names the limit instead of pretending the third blank was not typed.

Long answers are capped on screen, and the cap is printed

A very long rack can reach several thousand words, and painting all of them is slow on a phone. The page renders the longest 1,500 and then says exactly how many it found and how many it is not showing. The words dropped are always the shortest ones. A truncated list that does not declare itself truncated is the same failure as an invented word: it presents a partial answer as a whole one.

Questions

Why ship a dictionary at all, instead of asking a server?
Because a server that answers your rack is a server that receives your rack. Shipping the word list means the letters you type never need to be transmitted to be solved, and that is a much stronger statement than a privacy policy promising the same thing: the Content-Security-Policy on this site pins connections to this origin alone, so there is nowhere for a rack to go. The cost is that the word index is a real download, which is why it is split by word length, fetched only in the slices a rack can reach, and disclosed in bytes on the page that fetched it.
How is the index built, and can I check it?
An authoring tool in the repository reads wordlist/enable1.txt, sorts each word's letters to make its anagram key, groups every word that shares a key, and writes one file per word length. The output is byte-stable: same input, same bytes, forever, because nothing in the tool reads a clock, a locale or a random source. That is what lets the test suite regenerate the whole index and compare it to the shipped files byte for byte, and separately drive the real solver against a brute-force scan of all 172,820 words to confirm the two agree on every probe rack.
Why are 4,272 words in the file but not in the index?
They are 16 letters or longer. A rack on this site holds at most 15 characters, and a word longer than your rack can never be built from it, so indexing those entries would ship bytes that no query could ever reach. They remain in the shipped word list and you can read them there. The page says so rather than staying quiet, because a visitor who counts 168,548 and then reads 172,820 elsewhere should not have to guess which number is the lie.
Does the site keep anything on my device?
Nothing at all. There is no cookie, no local storage entry, no session storage, no IndexedDB record and no service worker. A rack lives in the text box until you change it and in the page's memory until you leave, and the browser discards both. That means nothing carries over between visits, which is a real cost — there is no history of racks you have solved — and it is the trade this site makes rather than an oversight.
What would make an answer here wrong?
Three things, and only one of them is a bug. The word list could disagree with the judge you actually care about, which it will, because it is a general English list rather than any game's official list. The list could be out of date relative to current usage, which it is, because it was compiled decades ago and is deliberately never edited here. Or the index could be wrong, which is the only defect this site can fix — and is the one thing the suite checks by regenerating the index and re-solving against a brute-force scan of the full word list on every run.

Where the evidence lives