LibreChessChess, explained simply

About

How LibreChess Works

LibreChess uses a local chess engine, two rules implementations and replayable source positions. Here is what those checks can establish, where judgement is still involved and when a result deserves a second opinion.

On this page
  1. The engine
  2. How the rules are enforced
  3. How moves are graded
  4. Classic-game studies and the Daily challenge
  5. How the five-minute coach chooses up to three insights
  6. Where the data comes from
  7. Authorship, review and corrections
  8. Changelog
  9. Privacy in one line
  10. Keep learning

The engine

Analysis and move grading prefer Stockfish 18 Lite WASM, distributed in stockfish@18.0.8 with the embedded nn-9067e33176e8.nnue NNUE network. It runs in a single-threaded Web Worker on the reader’s device and does not need cross-origin isolation; positions are not sent to a LibreChess analysis server. If it cannot start, LibreChess tries Stockfish 10 WASM fallback and then Stockfish 10 JavaScript fallback. The same local client powers play, hints, review and drill defence.

An engine result is conditional on the engine build, network, search limit and device. The lite Stockfish 18 build uses a much smaller network than full desktop Stockfish, and most LibreChess features deliberately use short searches to stay responsive. These results are useful for candidate moves and ordinary tactical errors, but they are not presented as correspondence-grade analysis. Re-run a critical position with a full current desktop engine and more time when the distinction matters. Exact worker URLs, hashes, package integrity, source commits and build commands are published in the engine manifest. The release check downloads each pinned npm tarball, validates its SHA-512 integrity, extracts only those declared engine paths into a temporary directory and byte-compares them with the files deployed by LibreChess.

How the rules are enforced

The FIDE Laws of Chess are the authority for over-the-board rules. LibreChess implements board play with chess.js; the main app also cross-checks moves with an independent Rust chess crate compiled to WebAssembly after that validator loads. Static practice boards use chess.js.

The casual play board automatically accepts an available threefold-repetition or fifty-move claim instead of reproducing the tournament claim procedure. A timeout is recorded as a draw for the common dead-material cases recognised by chess.js and when the would-be winner has a lone king. The formal rule remains broader: the game is drawn whenever no legal sequence could end in checkmate.

Two software implementations reduce the chance of an unnoticed move-generation bug; they do not turn the browser into a tournament arbiter. Claims that depend on game history, clock procedure, touch-move, claims made to an arbiter or an event’s supplementary regulations cannot always be decided from a FEN alone.

How moves are graded

Each searched position receives an engine evaluation. LibreChess converts centipawns to win probability with the public lichess curve and converts a player’s loss of win probability to a per-move accuracy score with the published lichess formula.

The labels are LibreChess thresholds: a drop of at least 10 percentage points is an inaccuracy, 20 is a mistake and 30 is a blunder. A move matching the engine’s first choice, or delivering mate, is labelled best. These names are a compact interface convention; they are not FIDE terms and need not match labels on another analysis site or at a different search depth.

Classic-game studies and the Daily challenge

The classic library contains 129 decisive games and 8,231 half-moves. 19 games have position-specific editorial notes at their turning points. The remaining 110 scores are presented as replay records with concrete board facts rather than padded out with generic commentary. Neither format assigns a player an intention unless an identified historical source supports it.

The offline reference uses Stockfish 17.1 with one thread, 32 MB hash, MultiPV 3 and a fixed 25,000 nodes for every position. Its complete evidence set was regenerated with a hash-pinned official 17.1 release binary after validating the exact UCI name and author and both embedded NNUE network identities; the executable was hashed again after all searches and the output is bound to the canonical score-corpus fingerprint. The result remains a bounded reference: it can distinguish the leading lines found in that search, but cannot prove an only move, exhaust every legal alternative or establish a player’s thought process.

The default Daily challenge selects three to five winner-side decisions from the same study record. The historical move scores three points. Another move scores two only when it is one of the stored MultiPV candidates within 0.35 pawns of that search’s leading line. All other legal moves are uncredited, not declared bad. The browser does no live grading search, so the same challenge produces the same result on every device.

Before publication, every score and stored engine line is replayed, every credited Daily move is checked and each result and move sequence is compared with a stored reference. These checks establish that the material is internally consistent and legal. They do not turn a strategic interpretation into a historical fact.

How the five-minute coach chooses up to three insights

The coach first ranks the selected player’s moves by how much they changed win probability. It then groups repeated versions of the same theme, so three hanging pieces do not become three near-identical cards. The result is at most three distinct moments, not a lecture on every imperfect move.

The plain-English causes are heuristics built from board features and short engine evidence. They can misidentify the reason for a move, especially in positions with several tactical ideas or a long strategic horizon. The continuation and board are the evidence; the theme label is a prompt to investigate, not an expert diagnosis.

The local learning profile keeps a bounded record for each completed review: a local de-duplication ID, completion time and up to five normalised theme observations with labels, bounded weights and same-site lesson links. It does not store the review’s PGN, FENs, moves, evaluations or prose explanations. A theme is called recurring only after it appears in at least two distinct completed reviews.

Where the data comes from

Authorship, review and corrections

Instructional pages are published under the responsibility of LibreChess. Rules and rating claims link to first-party material wherever possible, while legal positions and authored move sequences are replayed before publication. A named reviewer or specialist credential is shown only when it is genuine and relevant.

Material corrections are made in the maintained article, and the page date changes when its main advice or analysis changes. The editorial and corrections policy explains the standards used for sources, examples and uncertain claims; the correction route explains what evidence to include and shows whether a monitored submission destination has been configured.

Changelog

Privacy in one line

Your chess data — games, imported positions, local ratings, streaks, repertoire and settings — stays in browser storage or memory and is not uploaded for analysis. There are no accounts, ads or analytics cookies. LibreChess does use Plausible for aggregate traffic measurement; its events strip page and referrer queries and fragments, and do not include your moves, PGNs, FENs or study records. Ordinary page requests and the limited exceptions for query-string links are explained in the plain-language privacy details →

Keep learning