Sudoku Sudoku Online Puzzles is made by Brian Hamilton and Karan Hamilton.
Brian handles the puzzle logic, generators, solvers, data checks, and site code. Karan reviews pages from a player, family, classroom, and clarity perspective.
Our Puzzle Standard
Our aim is that a published Sudoku puzzle is fair, playable, and clear about what it is. For a standard Sudoku puzzle, that means the starting grid should follow the rules, have a valid completed solution, and avoid misleading the player with broken clues or incorrect answer keys.
For generated puzzles and prepared puzzle banks, we also aim for a unique solution. A unique solution matters because the puzzle should be determined by logic, not by choosing between several possible finished grids.
How Puzzles Are Generated
Most playable Sudoku pages start from a completed solution grid that satisfies the rules for that puzzle type. The puzzle is then created by removing entries or selecting a prepared puzzle string, depending on the page.
Classic 9x9 pages can use prepared puzzle lists for specific difficulty levels. Some harder banks are built offline so they can be checked more carefully before they are used on the site. Variant pages may generate a complete solution in the browser and then create a playable puzzle from that solution using the variant's extra rules.
Printable pages and the Sudoku Generator use puzzle banks where available and browser generation for other sizes or settings. The generated output includes the puzzle and the answer page so players can check their work after printing.
How We Check Solvability and Uniqueness
For classic Sudoku, our technical checks use solver logic to confirm that a puzzle can be completed and, where the page or bank requires it, that only one solution exists. The solver checks rows, columns, and 3x3 boxes and can reject grids with contradictions or multiple completions.
For difficult prepared banks, the offline build process records an audit trail such as the source puzzle, clue count, solution, search metrics, and difficulty signals. This gives us a stronger quality record than relying only on a page loading successfully in the browser.
For variants, the page checks the generated puzzle against its stored solution and variant rules. The exact checks vary by puzzle type because Killer, Jigsaw, Arrow, Anti-Knight, Wordoku, and other variants each add different constraints.
Do the Puzzles Require Guessing?
Our goal is that puzzles are solvable by logic. Easy and medium puzzles should open with straightforward scanning, singles, and candidate elimination. Harder labels may require stronger techniques, but a player should not be forced to guess blindly just because the puzzle is broken.
Computer validation sometimes uses search or branching internally to prove that a solution exists or is unique. That is different from expecting the player to guess. Search is a technical verification tool; the player-facing goal is still a fair logic puzzle.
For the hardest ratings, we are careful with wording. Some banks identify puzzles that stall after basic logic and show advanced difficulty signals, but that does not always prove that one named technique is strictly required. When we know a check is a ranking model rather than a full human-style proof, we avoid overstating it.
How Difficulty Labels Are Assigned
Difficulty labels come from a mix of givens, solving behaviour, puzzle-bank checks, and player feel. More starting clues usually make a puzzle easier, but clue count alone is not enough. A sparse puzzle can sometimes solve smoothly, while a fuller grid can hide difficult candidate patterns.
Easy puzzles are intended for relaxed play and basic logic. Medium puzzles ask for more scanning and candidates. Hard and expert puzzles may require pairs, locked candidates, fish patterns, wings, or other intermediate and advanced methods. Evil and extreme-style banks are selected more cautiously because those labels should feel meaningfully harder than everyday Sudoku.
Karan's player review matters here because a technically valid label still needs to feel right in play. If a page is confusing, the controls are awkward, or the explanation makes a puzzle feel harder than it should, that is part of the quality review too.
What Brian Checks Technically
Brian's technical work includes the puzzle generation code, solver logic, import and export formats, answer checking, browser behaviour, mobile controls, saved progress, and printable/PDF output where relevant.
For puzzle banks and harder levels, he checks that puzzles can be parsed, solved, stored, loaded, and matched with the correct solution. For solver tools, he checks that invalid grids, duplicates, unsolved grids, and solved outputs are handled clearly.
What Karan Reviews for Players
Karan reviews the pages from the point of view of a real player. That includes whether the rules are clear, whether the puzzle feels fair for the label, whether the page explains what to do next, and whether families, teachers, and casual players can use the page without needing technical knowledge.
She also helps catch wording that sounds clever but is not useful. A good puzzle page should explain enough to start playing and enough to recover when the player gets stuck.
How to Report a Bad Puzzle
If you find a puzzle that appears to have no solution, more than one solution, the wrong answer key, a broken control, or an unfair difficulty label, please use our contact page.
The most useful report includes the page URL, puzzle type, difficulty label, device and browser, and either the puzzle string, screenshot, or enough visible givens for us to identify the grid.
What Happens After a Correction Report
When a report comes in, we first try to reproduce the issue. For a puzzle problem, that usually means identifying the exact grid, checking the givens, comparing the expected solution, and testing the puzzle against the relevant solver or page logic.
If the puzzle or page is wrong, we correct it. That may mean removing a bad grid from a bank, updating a printable PDF, fixing a solver or generator bug, clarifying a rule explanation, or improving the page controls. If the issue affects more than one page, we look for the shared source rather than patching only the visible symptom.
Player reports are part of the quality system. They help us find edge cases that automated checks and our own testing may miss.
How This Relates to Editorial Standards
This page covers puzzle quality and testing. Our Editorial Standards page covers the wider publishing process: authorship, corrections, advertising, privacy links, and how we keep guides useful for readers.