Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Zobrist hashing and incremental position hashing are not competing algorithms. Zobrist hashing describes how an engine builds a compact key from position features; incremental hashing describes how it updates that key as a move changes the position. Chess engines commonly combine the two: they maintain a Zobrist key incrementally, often using XOR.

What each term means

A Zobrist key is a fingerprint assembled from keys assigned to features of a chess position. Those features can include a piece of a particular color and type on a particular square, whose turn it is, castling rights, and relevant en-passant availability. The engine combines the keys for the active features, commonly with XOR.

Incremental position hashing is an update strategy, not a different way of assigning feature keys. Rather than rebuilding the key from every feature after each move, the engine removes the contributions that changed and adds the new ones. MIT OpenCourseWare’s Fall 2018 Performance Engineering lecture explains this approach in the context of avoiding a full hash recomputation.

How an incremental Zobrist update works

XOR has a useful property for this bookkeeping: XORing the same value twice cancels it. So, when a piece moves, an engine can XOR out the key for that piece on its old square and XOR in the key for it on its new square. Other changed features are handled in the same way.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For example, in a simple schematic move where a white knight moves from one square to another, the update is conceptually:

key ^= white_knight_on_old_square ^ white_knight_on_new_square

This illustrates the operation; it is not a tested engine command or a complete move implementation. A real move may also change the side to move, capture a piece, alter castling rights, or affect en-passant status. XOR’s reversibility also makes it useful when restoring changed contributions during unmake, provided the engine restores all associated state consistently.

Why the key must represent more than the board

Two positions with the same piece placement can allow different legal moves. If the key omits state that affects legal continuations, it can treat distinct positions as though they were the same.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Side to move: White to move and Black to move are different positions for search purposes.
  • Castling rights: Rights can be lost when a king or rook moves, or when a rook on its original square is captured. The key must reflect changes to those rights.
  • En-passant availability: A legal en-passant capture changes the available move set. Engines need a consistent rule for when that state contributes to the key.

Stockfish’s current position.cpp is one concrete implementation example. It defines Zobrist key material for piece-square features, side, castling states, en-passant files, and a no-pawns key, and updates position keys during move handling. Its en-passant handling accounts for relevance to correct key generation and threefold checking. The file is on the moving master branch, so it documents that implementation as retrieved on October 4, 2026; it is not a fixed API specification for all engines.

Special moves make incremental bookkeeping demanding

Incremental updates are efficient only if every changed feature is accounted for. A normal capture changes the moving piece and removes the captured piece. A promotion changes the pawn into another piece. Castling moves both the king and rook and can change castling rights. An en-passant capture removes a pawn from a square other than the destination. Undoing the move must restore the board and the related state as well as the key.

Rank #4
WE Games Ultimate Chessplayer's Scorebook - Spiral Bound & Paperback Chess Notation Book with 50 Games & 100 Moves, Ideal Chess Score Sheets for Clubs & Tournaments
  • OCCASIONS: Whether you're competing in a tournament, participating in a chess club, or just starting out, this chess scorebook is designed for players of all levels. Its compact 8.54 x 5.59 x 0.51 design makes it easy to carry and the perfect fit for your chess bag.
  • COMPETITIVE CHESS: This chess scorebook features blank entry pages with pre-made tables, perfect for recording every move during chess tournament matches. This chess notation book can record up to 50 games with 100 moves per game (50 white / 50 black).
  • QUALITY: Paper back scorebook that is sprial bound, so it flips over just like a classic notebook. The cover boasts a pleasant light orange color. The cover also holds additional boxes for your own name to be filled out, and on the back there is a table of 25 opponents you have faced.
  • EDUCATIONAL: The benefits of chess are enormous. Those who partake in chess boost their critical thinking, problem solving, spatial awareness and socialization skills, making it a great addition to any household.
  • A TRUSTED BRAND SINCE 1977: WE Games has been committed to crafting traditional games for over four decades. Made with attention to detail and sustainable materials, we ensure that every chess notation book is built to last.

The community-maintained Chess Programming Wiki’s CPW-Engine move(0x88) example illustrates make/unmake handling for side to move, hash components, castling rights, and conditional en-passant tracking. It is a pedagogical example, not a universal engine design; its code also shows why these routines can become lengthy.

Incremental updates versus recomputing the key

Consideration Incremental Zobrist maintenance Full recomputation
Work after a position change Updates contributions for changed features instead of rescanning all position features. Traverses the current position and combines its active feature keys anew.
Implementation Requires correct updates and undo handling for ordinary and special moves, plus state changes. Provides a direct derivation from the represented position, but still depends on representing that state correctly.
Debugging Provides the maintained key used as search proceeds. Can serve as an independent reference to check whether the maintained key is correct.
Measured speedup No controlled head-to-head speedup is established by the cited sources. No cited benchmark compares full recomputation with incremental updates.

For search, incremental maintenance avoids repeating the full feature scan at every node in the described design. That is an algorithmic reason to use it, not a quantified performance guarantee: the cited material does not establish a speedup for a particular engine or workload.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How to check an implementation

  1. Implement a separate routine that recomputes the key from the current board and position state.
  2. After making and unmaking moves during development, compare that recomputed value with the incrementally maintained key.
  3. Include ordinary moves and special cases: captures, promotions, castling, en-passant captures, and moves that change castling rights or en-passant availability.
  4. When a comparison fails, inspect the board and state fields as well as the key; a mismatch can reveal either a hashing update error or an earlier make/unmake error.

What a matching key does—and does not—prove

A hash key is a compact fingerprint, not a mathematical proof that two positions are identical. Finite keys can collide, and transposition-table indexing can alias entries. Stockfish’s source explicitly discusses hash-position key aliasing when validating a move retrieved from the transposition table.

A transposition table stores results from previously performed searches so an engine can reuse work when search reaches a position again. Stockfish’s official Terminology documentation defines the table as “A database / hash table that stores results of previously performed searches.” Reuse is valuable, but it does not make a key infallible; engines need appropriate checking and validation around stored entries.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.