Chess Data Formats: ECO, Diagrams, SAN, FEN, PGN & UCI

Chess uses several representations because chess information exists at several different scopes.

A move is not a position. A position is not a game. A game is not an opening classification. A diagram is not automatically machine-readable state.

The final area teaches how to choose the representation that matches the task.

What ECO is

ECO refers to the Encyclopaedia of Chess Openings classification ecosystem associated with Chess Informant.

It classifies openings using codes beginning with:

• A;
• B;
• C;
• D;
• E;

followed by numeric subdivisions.

Examples:

• A13;
• B88;
• C65;
• D37;
• E60.

An ECO code is opening-classification metadata, not an explanation of the opening.

A–E families

At high level, ECO codes occupy five broad letter bands:

• A00–A99;
• B00–B99;
• C00–C99;
• D00–D99;
• E00–E99.

The exact opening assignment of every code belongs to opening-reference material.

The goal here is to understand ECO as metadata, not to reproduce the entire opening-code catalog.

ECO in PGN metadata

The PGN specification defines an ECO supplemental tag.

Example:

[ECO "C65"]

The original PGN specification describes forms such as:

• XDD;
• XDD/DD.

Modern data providers may vary in how deeply they use classifications/subcodes.

Opening name vs ECO code

Opening names are human language.

They can vary by:

• language;
• historical convention;
• naming depth;
• database provider;
• transposition policy.

ECO is classification metadata.

Therefore:

[ECO "C65"]
[Opening "Ruy Lopez"]
[Variation "Berlin Defence"]

contains related but different metadata fields.

Do not treat one opening name as a lossless translation of one ECO code in every database.

Opening names, transpositions and theoretical classification depth deserve their own opening-theory treatment.

Reading instructional chess diagrams

Instructional chess diagrams are editorial visual representations.

Their purpose is to make one position or relationship understandable visually.

House conventions should be explicit rather than assumed universal.

Orientation

A diagram should indicate:

• White-bottom;
• Black-bottom

when orientation may be ambiguous.

Default instructional diagrams can use:

• White at bottom

unless a lesson needs Black perspective.

Coordinates

Coordinate labels can be:

• full;
• edge-only;
• omitted for advanced drills.

If omitted:

• orientation must remain inferable or stated.

Side to move

When relevant, display explicitly:

• White to move;
• Black to move.

Do not infer from:

• which side is at bottom.

Highlights

Highlighted squares can indicate:

• target;
• region;
• attack;
• last move;
• candidate;
• error.

Color alone must not carry the semantics.

Arrows

Arrows may indicate:

• move;
• attack;
• route;
• plan;
• line.

Every visual context should explain what its arrows mean.

Last move

A diagram can optionally mark:

• origin;
• destination.

Candidate moves

Multiple arrows can show alternatives, but should not imply all were actually played.

Captions

A caption can preserve:

• side to move;
• task;
• relevant notation;
• source/context.

Diagram vs FEN vs PGN

Diagram

Best for:

• teaching visually;
• one position;
• one pattern.

FEN

Best for:

• copying/loading one position;
• exact side/castling/ep/counters.

PGN

Best for:

• complete game;
• move sequence;
• annotations/variations/metadata.

Visual position, textual position, and complete game are different data scopes.

Which representation should I use?

Choose representation by information scope, not by habit.

Representation conversions

Common transformations:

Board position → FEN

Requires invisible metadata beyond visible placement if full FEN is desired.

FEN → diagram

Render placement; preserve side/state separately.

Move on board → SAN

Requires current position/legal move set.

SAN sequence → game

Requires evolving board reconstruction.

Game → PGN

Add:

• metadata;
• SAN movetext;
• result.

PGN → position at move N

Replay from:

• standard start;
• or SetUp/FEN start.

SAN ↔ UCI move string

Requires current position because SAN may omit source while UCI includes it.

Many chess-format conversions are stateful. They cannot be performed from a token alone.

Think in information scopes

The easiest way to choose a chess format is to ask what object you are trying to preserve.

One move

Use SAN for human-readable move notation, or a coordinate/UCI move string inside an engine protocol context.

One position

Use FEN when exact machine-readable position state matters. Use a diagram when visual comprehension is the main goal. Often the best instructional artifact contains both.

One position plus a task

Use EPD when the position is the primary object and structured operations such as a best-move test must travel with it.

One game

Use PGN when metadata, move sequence, result and possibly variations/comments need to remain together.

One opening classification

Use ECO as classification metadata, usually alongside an opening name rather than as a replacement for explanation.

Information loss when converting formats

Conversions are not always reversible.

PGN → FEN

You can replay a PGN to obtain the FEN at a chosen moment, but that FEN no longer contains the earlier move sequence, comments or event metadata.

FEN → PGN

A FEN can become the starting position of a PGN using SetUp and FEN, but it cannot magically reconstruct the historical moves that produced the position.

Diagram → FEN

Visible piece placement is not enough to recover hidden state such as castling rights or counters unless those are shown separately.

UCI move string → SAN

The current position is required to infer piece type, capture status, disambiguation, check and mate.

Conversion can preserve the chess object you need while discarding information that belonged to a broader representation.

A representation matrix

House diagram conventions should be explicit

Instructional diagrams are presentation, so a site can choose its own visual language. The important requirement is consistency and accessibility.

A strong diagram system should make clear:

• orientation;
• side to move when relevant;
• what highlights mean;
• what arrows mean;
• whether a marked move is played, proposed or merely illustrative;
• the source/FEN when exact reconstruction matters.

Color should not be the only carrier of meaning. Labels, shapes, captions or other cues make diagrams more robust for accessibility and for monochrome reproduction.

Frequently asked questions

Is FEN better than PGN?

They solve different problems. FEN represents one position; PGN represents a game record and can include a FEN when the game starts from a non-standard position.

Is ECO a chess notation system?

It is better understood as opening-classification metadata. C65 labels a class; it does not encode a move or a complete position.

Should every chess article include PGN?

No. Use the smallest representation that preserves what the reader needs. A single tactical position may need only a diagram plus FEN and a short SAN line; a complete annotated game benefits from PGN.

Key takeaways

ECO:

• opening classification metadata.

Instructional diagrams:

• visual representations whose orientation and state conventions should be explicit.

Representation selection:

• SAN → move;
• FEN → position;
• PGN → game;
• EPD → position + operations;
• UCI move string → protocol move coordinates;
• ECO → opening classification.