UCI Chess Move Format & Engine Coordinate Notation

Human SAN compresses a move using the current position.

Engine-oriented interfaces often prefer an explicit coordinate form:

source square + destination square

Examples:

• e2e4;
• g1f3.

This is easier for software to exchange because the origin is explicit.

Coordinate / long move form

Basic shape:

<from><to>

Example:

• e2e4.

From:

• e2.

To:

• e4.

Unlike SAN:

• no pawn omission issue;
• no SAN disambiguation;
• source is directly encoded.

UCI move strings

The Universal Chess Interface — UCI — is a protocol used for communication between a chess engine and a graphical/interface program.

Its move format uses long algebraic/coordinate strings.

Official reference examples include:

• e2e4;
• e7e5;
• e1g1 for White short castling in orthodox chess;
• e7e8q for promotion.

UCI is the protocol. Move strings are one representation used inside the protocol.

Do not casually define:

UCI = e2e4 notation.

Promotion in UCI

Promotion appends a lowercase piece letter.

Examples:

• e7e8q;
• e7e8r;
• e7e8b;
• e7e8n.

Compare SAN:

• e8=Q.

UCI includes:

• source e7;
• target e8;
• lowercase promotion q.

Castling in orthodox UCI

Orthodox short castling:

• White e1g1;
• Black e8g8.

Orthodox long castling:

• White e1c1;
• Black e8c8.

This encodes the king source/destination in ordinary chess.

Chess960 nuance

UCI has additional handling/options for Chess960 castling representation.

Do not generalize orthodox e1g1 as the only castling representation in every variant context.

Null move representation

In UCI protocol context:

• 0000

represents a null move sent from engine to GUI in the relevant protocol use.

This is not:

• an ordinary legal chess move a player can make over the board.

Protocol control representation can contain tokens that are not player moves.

SAN vs UCI move strings

Example

Position allows White knight g1-f3.

SAN:

• Nf3.

UCI:

• g1f3.

Capture

SAN:

• Bxc6+.

UCI:

• source+destination only, for example b5c6.

The move string does not itself say:

• capture;
• check.

Those facts are inferred from position/result.

SAN encodes human semantics compactly. UCI move strings encode explicit coordinates compactly.

UCI is a protocol

UCI includes far more than move strings.

Conceptually it defines communication such as:

• identifying the engine;
• setting options;
• supplying a position;
• starting search;
• reporting analysis;
• returning a best move.

For move-format literacy, it is enough to recognize the protocol context. Principal variations, depth, evaluation and practical engine-analysis workflow are separate topics.

Common mistakes

"e2e4 is SAN."

Wrong. SAN from the initial position is:

• e4.

"UCI move strings explicitly mark captures."

Wrong. There is no SAN-style x.

"UCI move strings include + and #."

Not in the standard move format.

"0000 is a legal player move."

Wrong. It is a protocol null-move representation.

"UCI is only a notation system."

Wrong. It is a GUI ↔ engine protocol.

Why coordinate moves are convenient for engines

A GUI already knows the board state. If it sends g1f3, the engine or interface can identify the moving piece from g1 and the destination from f3 without requiring SAN-style origin disambiguation.

This makes coordinate move strings compact and deterministic for software communication.

The trade-off is that they carry fewer human-readable semantics. b5c6 does not visibly tell you:

• that a bishop moved;
• whether it captured;
• whether the move gave check.

Those facts come from the position before and after the move.

UCI moves live inside a position context

The UCI protocol does not normally send isolated moves with no board state. A GUI supplies a position and then communicates moves or search commands in relation to that state.

Conceptually:

position startpos moves e2e4 e7e5 g1f3

The important lesson is not to memorize one command line. It is to understand that e2e4 is interpreted against a known position sequence.

Converting SAN to UCI and back

SAN → UCI

Given the position and SAN Nf3:

1. parse the SAN;
2. identify the unique legal knight move to f3;
3. recover the origin square, for example g1;
4. output g1f3.

UCI → SAN

Given the position and b5c6:

1. identify the piece on b5;
2. determine whether c6 is occupied and whether the move is legal;
3. determine whether SAN disambiguation is required;
4. determine check or mate in the resulting position;
5. construct the SAN token, perhaps Bxc6+ in a matching position.

Neither direction is a safe string-only substitution.

Castling and variant context

For orthodox chess, UCI examples encode castling as the king's coordinate move, such as e1g1 or e1c1 for White.

Chess960 complicates castling representation because king and rook starting squares vary. Software may use the UCI_Chess960 option and variant-aware conventions. When working outside orthodox chess, do not assume that ordinary-start castling examples describe every implementation context.

Frequently asked questions

Is e2e4 "long algebraic notation"?

The UCI specification describes its move format as long algebraic notation, but in practical discussion it is often clearer to call these source-destination coordinate move strings so they are not confused with SAN.

Does UCI say whether a move is a capture?

Not directly in the move string. The source/destination pair is interpreted against the current position.

Is 0000 something a player can play?

No. It is a protocol null-move representation used in engine/GUI communication, not an ordinary legal over-the-board move.

Key takeaways

UCI coordinate move strings use:

• source;
• destination;
• optional lowercase promotion suffix.

Representative forms:

• e2e4;
• g1f3;
• e1g1 orthodox castling;
• e7e8q promotion;
• 0000 protocol null move.

Critical distinction:

SAN ≠ UCI move string. UCI move string ≠ whole UCI protocol.

Check your understanding

• [ ] I read source+destination coordinate moves.
• [ ] I recognize common UCI move strings.
• [ ] I know promotion uses lowercase suffix.
• [ ] I understand orthodox castling representation.
• [ ] I recognize 0000 as protocol null move.
• [ ] I can compare SAN and UCI forms.
• [ ] I understand UCI is a protocol.