The First Realization: A Chessboard Is Only 64 Squares#

A chessboard looks large to a beginner.

But to a computer, it is tiny.

There are only 64 squares. That means any square can be represented with just 6 bits, because:

1
2^6 = 64

So instead of storing a move as text like:

1
Nf3

or:

1
exd5

we can store it as two square coordinates:

1
from_square -> to_square

For example:

1
e2 -> e4

One square needs 6 bits.

Two squares need:

1
6 bits + 6 bits = 12 bits

That means most normal chess moves can be represented in only 12 bits.

This is the simplest binary approach:

1
[from: 6 bits][to: 6 bits]

It is compact, direct, and fast to decode.

The reader does not need to parse SAN. It does not need to understand whether "Nbd2" means the knight from b1 or f3. It does not need to interpret captures, checks, checkmates, or castling notation. It simply reads two square IDs and applies the move.

The chess rules are still needed to update the board correctly, but the move identity itself is no longer hidden inside text.

Castling and en passant fit naturally into this scheme. For castling, we encode the king’s from-square to its destination: e1→g1 for kingside, e1→c1 for queenside. The rook move is implied by the rules. For en passant, we encode it as a normal pawn capture using the from-square and the destination square. The capture of the opponent’s pawn is a board-state consequence.

The Promotion Problem#

Chess always has exceptions.

Most moves can be represented with a starting square and a destination square. But promotions need one extra piece of information.

If a pawn reaches the final rank, it can promote to one of four pieces:

1
Queen
2
Rook
3
Bishop
4
Knight

Four possibilities require 2 bits:

1
00 = queen
2
01 = rook
3
10 = bishop
4
11 = knight

So a promotion move can be stored as:

1
[from: 6 bits][to: 6 bits][promotion: 2 bits]

That gives us:

1
12 bits + 2 bits = 14 bits

So with a simple coordinate-based binary encoding, we can represent almost every chess move in 12 bits, and promotion moves in 14 bits.

Compared to PGN text, that is already a major improvement.

Why This Is Already Better Than PGN#

Let’s take a common PGN move:

1
Nxd4

That is four characters. In a normal text encoding, each character usually costs 8 bits.

So this move alone costs roughly:

1
4 characters × 8 bits = 32 bits

And that does not include spaces, move numbers, comments, variations, line breaks, or metadata.

PGN is also more expensive to interpret than its size alone suggests. A PGN parser must deal with disambiguation like "Nbd2", "R1e2", or "exd5". To understand those moves, the parser must reconstruct the board state, find legal pieces that can reach the target square, and determine the correct one. PGN is semantic text that requires chess-aware parsing.

A coordinate move costs about:

1
12 bits

And it needs no chess-aware parsing to identify the move. The system reads two square IDs and applies the move directly.

A rough comparison looks like this:

1
PGN text move:       ~24–40 bits or more
2
Binary coordinates: ~12–14 bits

That is the first big lesson:

PGN was designed for readability and portability, with compactness as a secondary concern.

The Second Realization: Maybe We Don’t Need Coordinates at All#

We can do better.

At any given chess position, the number of legal moves is limited.

A player does not have 4,096 possible moves. They usually have something like 20, 30, 40, or maybe 50 legal moves. The theoretical maximum is 218 legal moves (requiring 8 bits), but such positions are vanishingly rare in practice.

So instead of storing:

1
from_square -> to_square

we could do something more clever.

Imagine that both the writer and the reader generate the exact same list of legal moves for the current position:

1
0: e2e4
2
1: d2d4
3
2: g1f3
4
3: c2c4
5
...

Then we do not need to store the move itself.

We only need to store its index.

If the move played was the third move in the list, we store:

1
2

That is the legal-move-index approach.

Instead of asking:

Which square did the piece move from, and where did it go?

we ask:

Out of all legal moves in this position, which one was chosen?

This can be much smaller.

If a position has fewer than 64 legal moves, the index fits in 6 bits.

If it has fewer than 128 legal moves, it fits in 7 bits.

Most chess positions fit comfortably in that range.

So now our rough comparison becomes:

1
PGN text:           ~24–40 bits per move
2
Coordinates:        ~12–14 bits per move
3
Legal move index:   ~6–7 bits per move

That is a dramatic reduction.

The Beautiful Edge Case: Forced Moves Cost Almost Nothing#

This approach has an elegant consequence: forced moves cost nothing.

Sometimes a player has only one legal move.

For example, in a forced checkmate sequence or a position where every move except one is illegal, there may be exactly one valid choice.

If there is only one legal move, we do not need to store anything.

The decoder generates the legal move list, sees that only one move exists, and applies it automatically.

The move costs:

1
0 bits

That feels almost magical.

But it is not magic. It is simply using the rules of chess as shared context between the encoder and decoder.

When the rules determine the answer, the file does not need to repeat it.

This is the core principle behind many efficient encodings:

Do not store information that can be reconstructed deterministically.

The Catch: Compression Is Not Free#

At this point, legal-move indexing sounds like the obvious winner.

Why store 12 bits when we can store 6?

Why use coordinates at all?

The answer is performance.

To decode a coordinate-based move, the reader does something simple:

1
Read from-square
2
Read to-square
3
Apply move

This is extremely fast.

To decode a legal-move index, the reader must do more work:

1
Generate all legal moves
2
Sort/order them deterministically
3
Read the index
4
Select the matching move
5
Apply move

That means every move requires legal move generation.

For a single game, this is fine.

For millions of games, it becomes expensive.

Compression is only half the problem. A chess database is also a performance problem.

If your format is beautifully small but slow to scan, slow to open, slow to index, or difficult to randomly access, it may be worse in practice than a larger format.

This gives us the fundamental trade-off:

1
Smaller files usually require more computation.
2
Faster decoding usually requires storing more explicit information.

There is no universal best answer. There is only the best answer for a specific system.

1
[from square][to square][optional promotion]

1
[index of move in legal move list]

The Practical Design Choice#

For a modern chess database, I would start with coordinate-based binary moves.

Something like:

1
12 bits for normal moves
2
14 bits for promotions

This gives an excellent balance:

1
Much smaller than PGN
2
Much faster to parse than PGN
3
Simple enough to implement safely
4
Efficient for massive databases
5
Friendly to random access and indexing

Legal-move indexing can still be useful later, especially for a compressed distribution format or cold storage format.

But for the primary editable database representation, coordinates are a better foundation.

This leads to a layered architecture:

1
Internal database format: coordinate-based binary moves
2
Optional archive format: legal-move-index compression
3
Export format: deterministic PGN

That way, each format does what it is best at.

PGN remains the universal language for humans and existing tools.

The binary coordinate format becomes the fast internal representation.

The legal-move-index format becomes an optional compression layer for distribution or archival storage.

What About the Initial Position?#

So far, we assumed that every game starts from the normal chess starting position.

But real databases also contain games that begin from custom positions:

• Chess960 games.
• Training positions.
• Composed studies.
• Partial game fragments.
• Engine lines.
• Positions imported from FEN.

For those cases, the format needs to store the initial board state.

The usual text format for this is FEN:

1
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

FEN is useful and readable, but again, it is text.

A binary format could store a compact “Bit-FEN” instead.

At minimum, an initial position needs:

• Piece placement.
• Side to move.
• Castling rights.
• En passant square, if any.
• Halfmove clock.
• Fullmove number.

The exact encoding can vary, but the principle is the same:

Store chess state as structured binary data, not as text that must be reparsed.

For normal games, we can omit the initial board entirely and assume the standard starting position.

For custom games, we include a compact binary initial-state block.

That gives us efficiency without losing generality.

Conclusion: PGN Is the Beginning, Not the End#

PGN gave chess software a common language.

But modern chess software can go beyond it.

A binary chess format can represent moves in 12 to 14 bits using coordinates. With legal-move indexing, it can sometimes approach 6 to 7 bits per move, or even 0 bits for forced moves.

But the smallest format is not always the best format.

For an interactive chess database, the best design is likely a pragmatic one:

1
Use binary coordinates for speed.
2
Use legal-move indexing where compression matters.
3
Use PGN for import and export.
4
Use a compact binary position format for custom starting states.

That gives us a layered system where each format plays to its strength:

1
Human compatibility.
2
Machine efficiency.
3
Fast random access.
4
Compact storage.
5
Deterministic export.
6
Room for future compression.

PGN remains useful.

But it does not have to be where the story ends.

Sometimes the real breakthrough begins when we stop asking:

How do we store the notation?

And start asking:

What is the smallest useful truth the machine actually needs?