Moves, Optimal, Undo, Reset, and Solve put the puzzle and the answer in the same place. The odd rule that the keeper must finish on a goal makes the last few moves matter more, and board 15 should say upfront that Solve replays a precomputed route.
Sokoban AI Solver
Play Sokoban puzzle online and watch an AI solve it optimally in your browser.
1 ratings4.09
Saves72
CategoryGames
PlatformWeb
PricingFree
A browser-based Sokoban puzzle game with an AI solver implemented in JavaScript. It uses a ported native C++ engine that computes the provably optimal (fewest-move) solution entirely client-side using an advanced A* search algorithm. Players can move the keeper to push boxes onto goals, undo moves, reset boards, and watch the AI solve various boards with move-optimal solutions.
Ratings & Reviews
Write a reviewInformation
CategoryGames
PlatformsWeb
PricingFree
AccountNot confirmed
ListedAugust 2026
WebVisit
Report a problem
Website checks
Mobile PageSpeed
Automated checks of the public website by Google Lighthouse 13.5.0. Scores can vary between runs.
Checked Oct 24, 2026
Test this website on PageSpeedWebsite checks refresh automatically each week.
- Performance
- 99 out of 100, Good
- Accessibility
- 100 out of 100, Good
- Best Practices
- 100 out of 100, Good
- SEO
- 100 out of 100, Good
Around the Web
Show HN72 source points · 42 comments
“What runs here is a plain-JavaScript port of a native C++ optimal solver I wrote.” Seems to be AI in the older sense from 10 years ago?
GPerson · Imported from Show HN
While impressive that the optimal can be proven, I feel like the example puzzles here aren't ones that are particularly hard to find solutions for (when move count doesnt matter). I'd be interested to see at least one example that has a lot of tricky dead states that would act as traps.
cbondurant · Imported from Show HN
Intuitively, I feel like the final board might also be able to be tackled in browser, if you use WASM and speed up the solver. I wonder: maybe the state is overly compressed? Could it speed things up to store (boxes, [every position the keeper can reach without pushing]) rather than (boxes, representative keeper position), so we can reduce recomputation of the keeper walking around? I wonder: maybe A* is counterproductive, as obvious heuristics have traps? Maybe BFS is better? I wonder: the search doesn't actually "skip over" walking states, it just hides them in the processing of each element in the queue, so adding them to the queue might actually be faster? I wonder: are there any other simple pruning techniques that you could incorporate? Any learnings from state-of-the-art Sokoban solvers, like this one? -- https://ieee-cog.org/2020/papers/paper_44.pdf Many interesting questions... sadly, the webpage is written by AI, so there's zero discussion of these tradeoffs, future avenues, or rejected ideas, in favor of meaningless self-congratulatory copy about the "provable optimum" and silly claims like a bucket queue being allocation-free.
npinsker · Imported from Show HN
Compared to original sokoban game, the player's final position does not matter, and the number of boxes is strictly equal to the number of goal marks.
qbane · Imported from Show HN
Fun game! Solver seems really smart. It would be great to disable double tap to zoom or make it slightly more adapted to phone screen sizes
Sebastian_09 · Imported from Show HN