Word Search Puzzle Grid — Free HTML CSS JS Snippet

Word search puzzles look simple from the player's side — find the hidden words in a grid of letters — but building one that actually works requires solving two distinct problems: placing words into a grid without illegal overlaps, and detecting a valid straight-line selection dragged across that grid. This snippet solves both from scratch in vanilla JavaScript, producing a genuinely playable 10×10 puzzle with eight target words, click-and-drag (and touch-drag) selection, and permanent per-word highlight colours.

Placing words without silently failing

buildPuzzle() iterates the word list in shuffled order and, for each word, repeatedly attempts a random placement: pick one of three directions — horizontal, vertical, or diagonal down-right — then pick a random starting cell constrained so the word fits fully inside the 10×10 bounds (maxX/maxY subtract the word's length from the grid size along the axis that direction moves). Before committing a placement, the code walks every cell the word would occupy and checks existing !== null && existing !== word[i] — meaning a placement is only rejected if a cell is already occupied by a different letter than the one this word needs there. This deliberately allows words to legitimately cross and share a letter (a common, expected word-search feature) while still preventing letter corruption. Each word gets up to 200 randomised attempts before giving up, which in practice is more than enough headroom for eight words of five letters on a 100-cell grid.

Filling the gaps and the direction set

After every word is placed, any grid cell still null is filled with a uniformly random letter from A-Z. The three supported directions — horizontal (dx:1, dy:0), vertical (dx:0, dy:1), and diagonal down-right (dx:1, dy:1) — cover the requested scope of straight lines in forward orientations without needing to support reversed/backwards placement, keeping the generation logic and the matching logic symmetric and simple.

Detecting a valid drag selection

As the player drags across the grid, cellsBetween(a, b) determines whether the current start and end cell form a legitimate straight line: it computes the sign of the x and y deltas (Math.sign) to get a per-step direction, then rejects the selection if the horizontal and vertical distances aren't equal (which would mean the drag isn't running along a true horizontal, vertical, or 45-degree diagonal). If the line is valid, it builds the ordered list of cells from start to end using that per-step direction — this is the same directional-stepping logic used by the placement algorithm, just running in reverse to validate rather than generate.

Matching in either direction along the line

On release, tryMatchSelection() reads the letters under the selected cells in order (selectionWord()) and also computes the reversed string, then checks both against the list of not-yet-found target words. This means a player can drag a horizontal word either left-to-right or right-to-left, and a vertical word either top-to-bottom or bottom-to-top, and it will still register correctly — natural behaviour for click-and-drag selection where the player doesn't necessarily know which end of a word they'll spot first.

Distinct per-word highlight colours and persistent state

Each placed word is assigned an index at generation time, and a found match adds both a shared .found class and a word-specific .found-N class (mapped to eight distinct accent colours in CSS) to its cells — so once a word is found, its path through the grid stays permanently and distinctly highlighted, and it's struck through in the sidebar checklist via renderWordList(). Touch support uses document.elementFromPoint() to resolve which grid cell is currently under the user's finger during a touchmove, since touch events don't naturally target the element being dragged over the way mouse events do.