Most word-solver and unscrambler tools online work the same way: you type in a set of letters, the page fires off a request to a server, the server searches a database, and a second or two later you get results. It works, but it never feels instant, and it means the tool is useless the moment your connection drops.
When I built WordScrambler, I wanted something different: type letters, get every valid match back before you've even finished typing, with zero network requests after the page loads. That meant the entire 246,000 word dictionary needed to live and be searchable client side, in the browser, with no server round trip doing the heavy lifting.
Here's what that actually took to get right.
The core problem
Searching 246,000 words sounds trivial until you think about what "search" actually means for a word game tool. Users aren't just typing a word to look up. They're asking questions like:
- "What words can I make from these 7 letters?" (anagram / unscramble)
- "What words start with these letters and are 5 letters long?" (word finder / pattern match)
- "What real words exist inside this jumble?" (Scrabble and Words with Friends style lookups)
Each of those is a different kind of query, and a naive approach, looping through 246,000 words and checking each one against the input, is fast enough on paper but starts to feel sluggish the moment you're running it on every keystroke on a phone.
The approach
The fix was to do the expensive work once, ahead of time, rather than on every search.
Instead of storing the dictionary as a flat list, I pre-processed it into an optimized in-memory index at build time. The key idea: group words by a normalized signature (their letters sorted alphabetically), so that "learn" and "lanre" and "renal" all map to the same signature and sit in the same bucket. Once that index exists, an anagram or unscramble query stops being a search problem and becomes a single lookup: sort the input letters, check the index for that exact key, and return whatever's sitting there. That turns an O(n) scan across the whole dictionary into an O(1) lookup.
Word-finder style queries (prefix matches, pattern matches with wildcards) get their own lighter index built the same way, grouped by starting letters and word length, so the browser only ever has to check a small, relevant slice of the dictionary rather than all 246,000 words.
The tradeoffs
None of this is free. A precomputed index for a quarter-million words is bigger than the raw word list, so there's a real tension between search speed and how much data has to ship to the browser on first load. A few things helped keep that in check:
- Compressing the dictionary payload so the initial download stays small, then building the in-memory index client side after it arrives, rather than shipping the index itself pre-built.
- Loading the dictionary in the background after the page becomes interactive, so the page doesn't feel like it's waiting on 246,000 words before it's usable.
- Keeping the index structure flat and simple (plain object lookups rather than anything more exotic) so the browser's own JS engine can optimize access without extra overhead.
The result is a tool that loads fast, then gets faster the more you use it, since once the index is built, every subsequent search is effectively instant.
Why this matters beyond word games
This isn't really a word game problem, it's a general lesson about where computation belongs. A lot of tools default to "send it to a server" as the answer to "how do I search a lot of data," when for datasets in this size range (hundreds of thousands of entries, not millions), a well-structured client side index can outperform a network round trip every time, and it keeps working offline, with no server costs, and no rate limits.
If you're building something similar and want to see this in action, the live version is here, free to try, no signup needed. Type in a scrambled word or a set of letters and watch how fast the results come back, that instant response is the in-memory index doing its job.
If you want to compare notes on dictionary indexing, anagram lookups, or client side search in general, drop a comment, I'd like to hear how other people have approached the same tradeoff.
Top comments (0)