Skip to content
Notation, Recording & Chess DataGuide

Chess Notation & Data Practice: SAN, FEN, PGN, EPD & UCI

Test your ability to move between a chessboard and its written representations with practical SAN, FEN, PGN, EPD, UCI, scoresheet and format-selection exercises.

The purpose of this practice guide is not to turn every reader into a format implementer.

It is to make chess representations readable, writable, and distinguishable.

The final test is reconstruction:

Can the reader move reliably between board events and the representations used by chess literature and software?

Reconstruction practice

SAN → move on board

Given:

  • a legal position;
  • SAN token.

Task:

  1. identify moving piece;
  2. resolve disambiguation;
  3. identify capture;
  4. destination;
  5. promotion;
  6. resulting check/mate;
  7. update board.

Example:

  • Nce2.

The position is required to know the exact c-file knight origin square.

Board move → SAN

Given:

  • position;
  • explicitly selected legal move.

Task:

  1. find same-type legal ambiguity;
  2. construct canonical SAN;
  3. append state suffix.

This tests legality reasoning and notation construction together.

FEN → position

Task:

  • decode eight ranks;
  • orient board;
  • set side to move;
  • castling rights;
  • ep target;
  • counters.

Then answer:

Which state is not visible from placement alone?

Diagram → FEN

Task must supply or state assumptions for:

  • side to move;
  • castling;
  • ep;
  • clocks.
Warning

A bare diagram is not enough for a fully determined FEN in general.

PGN → game

Task:

  1. read tags;
  2. choose initial position;
  3. replay SAN;
  4. follow main line;
  5. inspect RAVs separately;
  6. preserve result.

Game fragment → PGN/SAN

Given a short legal sequence:

  • write SAN;
  • add move numbers;
  • add termination marker;
  • wrap in minimal metadata when requested.

EPD → task

Read:

  • four position fields;
  • bm/am/id operation.

Explain:

  • what the position asks.

SAN ↔ UCI

Given position:

  • SAN Nf3;
  • identify source g1;
  • UCI g1f3.

Given UCI:

  • e7e8q;
  • reconstruct SAN based on position, including capture/check if applicable.
Key idea

SAN↔UCI conversion is position-dependent because the formats encode different information.

Mixed notation and data exercise set

Exercise set

1. Human vs PGN castling

Which is Appendix-C style?

  • 0-0.

Which is canonical SAN?

  • O-O.

2. Promotion forms

Human FIDE example:

  • d8Q.

PGN SAN:

  • d8=Q.

3. Local piece letters

Explain why a local scoresheet can differ from PGN English SAN.

4. Pawn capture

Decode:

  • exd5.

5. Complex SAN

Decode:

  • fxg8=N+.

6. Disambiguation

Two legal knights reach e2:

  • choose Nce2/Nge2.

7. Pinned ambiguity

Pinned knight geometrically reaches target but cannot legally move. Question: Does it force SAN disambiguation? Answer: No.

8. Move-number fragment

Read:

  • 17...Nf6.

9. RAV

Identify which move the variation replaces.

10. NAG

What does $1 encode conceptually?

11. Objective vs subjective

Classify:

  • +;
  • #;
  • !;
  • ±;
  • $2.

12. Scoresheet marker

What can = mean in a FIDE scoresheet context?

  • draw offer marker.

13. FEN fields

Name all six in order.

14. FEN starting position

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

15. FEN ep nuance

After a double push, can the target field exist even if no capture is available under the traditional spec? Answer: Yes.

16. FEN legality

Can syntactically valid FEN describe an illegal chess position? Answer: Yes.

17. PGN STR

List seven tags in order.

18. Result consistency

Find mismatch between tag and movetext termination.

19. Nonstandard start

Which tags?

  • SetUp "1";
  • FEN "...".

20. PGN import/export

Which is more permissive?

  • import.

21. EPD

What distinguishes EPD from FEN?

  • four-field core + operations.

22. EPD opcode

Recognize:

  • bm;
  • am;
  • id.

23. UCI move

Decode:

  • g1f3.

24. UCI promotion

Decode:

  • e7e8q.

25. Null move

What is 0000?

  • UCI protocol null-move representation, not an ordinary player move.

26. ECO

What does C65 do?

  • classifies an opening family/entry; does not explain how to play it.

27. Diagram vs FEN

Which stores castling rights directly?

  • FEN.

28. Diagram side to move

Can it always be inferred visually?

  • no.

29. Representation choice

Best format for one position?

  • FEN.

Best for whole annotated game?

  • PGN.

30. Conversion

Given position + SAN, produce UCI; then reverse.

A complete representation workflow

A strong notation workflow is not about memorizing isolated syntax. It is about moving between representations without changing the underlying chess event.

Consider a short sequence played on a board.

You may need to:

  1. verify each move is legal;
  2. write each move in SAN;
  3. place the sequence into numbered movetext;
  4. wrap it in PGN metadata;
  5. replay the record to a target move;
  6. export that position as FEN;
  7. render a diagram from the FEN;
  8. convert one candidate move to a UCI coordinate string;
  9. attach a best-move task in EPD.

Every transformation changes the representation, not the underlying chess position or move.

Diagnose errors by layer

When a conversion fails, first ask which layer is wrong.

Board or legality error

The represented move cannot legally occur.

SAN error

The move is legal, but the SAN token has wrong capture, disambiguation, promotion or check/mate syntax.

FEN error

The position string has bad fields or inconsistent state.

PGN error

Tags, result, variations, comments or movetext structure are malformed or inconsistent.

Protocol/data error

A UCI/EPD token is being interpreted outside the correct position or protocol context.

This prevents one of the most common debugging mistakes: trying to fix a representation string when the actual problem is the chess state it was supposed to describe.

Translation and localization rules for chess data

Localization must preserve the difference between reader-facing language and invariant data tokens.

Translate or adapt:

  • explanatory prose;
  • headings and captions;
  • human-friendly opening names where appropriate;
  • examples of local scoresheet piece initials when the guide is explicitly teaching human notation.

Keep invariant inside raw technical examples:

  • PGN SAN piece letters K Q R B N;
  • PGN tag names in actual PGN data;
  • FEN piece letters and state tokens;
  • UCI coordinate move strings;
  • ECO codes;
  • EPD opcodes when demonstrating the actual format.

This rule will matter when the English guides are localized: the explanation should feel native in each language without corrupting portable chess data.

What mastery looks like

You do not need to become a PGN parser author or memorize every EPD opcode.

You should be able to:

  • recognize which representation you are looking at;
  • explain what information it preserves;
  • reconstruct the relevant board state when required;
  • choose the right representation for a task;
  • spot common syntax/context errors;
  • move between SAN, FEN, PGN and UCI when the position context is available.

That is enough notation and data literacy to support deeper tactical, strategic, analytical and software-oriented chess work.

Representation mastery check

You have a strong working foundation when the following skills are functional.

Algebraic/SAN

  • read ordinary moves;
  • captures;
  • check/mate;
  • castling;
  • promotion;
  • en passant;
  • results.

Disambiguation

  • legal candidates only;
  • file;
  • rank;
  • full origin.

Annotated chess

  • fullmove/ply;
  • White/Black fragments;
  • comments;
  • RAV;
  • nested RAV;
  • !/? family;
  • evaluation symbols;
  • NAGs.

Scoresheets

  • basic human layout;
  • local piece letters;
  • draw-offer marker;
  • paper/electronic concept;
  • transcription to PGN.

FEN

  • six fields;
  • build/decode;
  • castling rights semantics;
  • traditional ep target nuance;
  • halfmove/fullmove;
  • syntax vs legal position.

PGN

  • STR;
  • supplemental tags;
  • movetext;
  • comments/RAV/NAG;
  • SetUp/FEN;
  • import vs export;
  • Result consistency.

EPD

  • four-field relation to FEN;
  • operations;
  • purpose.

UCI

  • source/destination move string;
  • promotion;
  • castling;
  • null move;
  • protocol distinction.

ECO / diagrams

  • classification metadata;
  • opening name distinction;
  • instructional diagram conventions;
  • representation selection.
Checklist

Final checklist

  • [ ] I can read and write canonical SAN.
  • [ ] I distinguish FIDE human notation from PGN SAN.
  • [ ] I can follow annotated variations.
  • [ ] I can read a scoresheet.
  • [ ] I can parse/build basic FEN.
  • [ ] I can read/write a simple PGN.
  • [ ] I understand EPD purpose.
  • [ ] I recognize UCI coordinate moves.
  • [ ] I understand ECO metadata.
  • [ ] I know which representation matches which task.

Where to go deeper

Chess legality

Use the dedicated rules guides for complete legal-move, check, castling, en-passant, promotion and draw-state treatment.

Board geometry

Use the board-vision guides for coordinate fluency, rays, attack maps, mobility and visualization.

Tactical interpretation

Move on to tactics once you can record and reconstruct positions accurately.

Opening theory and classification depth

Use opening-specific material for transpositions, repertoires and the practical meaning behind ECO labels.

Engine analysis workflow

Engine scores, depth, principal variations and database workflows require a separate analysis layer.

Tournament scoresheet procedure

Competition rules cover recording obligations, time-pressure exceptions, arbiters and electronic scoresheet procedure.

Variant-specific representation

Chess960 and other variants may extend or reinterpret orthodox representation conventions.

Localization rule for technical chess data

Chess notation creates an important localization constraint: human explanation can change language while portable technical tokens often must not.

May localize

  • explanatory prose;
  • customary human scoresheet piece letters/examples;
  • displayed opening names when appropriate.

Do not translate inside canonical technical strings

  • PGN SAN data;
  • FEN piece codes;
  • UCI move strings;
  • ECO codes;
  • PGN tag names when showing actual raw PGN.
Key idea

Translate the explanation, not the invariant data token.

Why this matters for deeper chess study

Once moves and positions are readable outside the board, tactical and strategic ideas can be described precisely and reproduced reliably.

A fork can be shown as:

  • diagram;
  • FEN;
  • SAN sequence;
  • annotated PGN fragment.

Notation and data literacy therefore acts as infrastructure for deeper chess study.

Final mental model

Chess information has layers:

BOARD EVENTSAN / human move recordFEN position snapshotPGN game recordEPD position task / UCI protocol move / ECO metadata

Not every layer contains the others.

Key idea

Represent the right chess object with the right format.