PGN Explained: Tags, Metadata & Movetext

Portable Game Notation — PGN — is a plain-text representation designed to exchange chess game data.

It is readable by:

• people;
• programs.

But PGN is more than:

• "a list of moves."

A PGN game contains two major sections:

1. tag-pair section;
2. movetext section.

Movetext ends with a game termination marker.

PGN structure

Example skeleton:

[Event "Example"]
[Site "?"]
[Date "2026.08.26"]
[Round "1"]
[White "White"]
[Black "Black"]
[Result "1-0"]

1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 1-0

Tag section

Metadata in square brackets.

Blank separation

Canonical export places a blank line between tags and movetext.

Movetext

• move numbers;
• SAN moves;
• optional annotations/comments/variations;
• termination marker.

PGN = metadata + game movetext, not movetext alone.

Tag-pair anatomy

A tag pair has:

• opening bracket [;
• tag name;
• quoted string value;
• closing bracket ].

Example:

[White "Carlsen, Magnus"]

Tag name:

• White.

Value:

• Carlsen, Magnus.

Seven Tag Roster — STR

The original PGN specification defines seven mandatory archival tags in this order for export:

1. Event
2. Site
3. Date
4. Round
5. White
6. Black
7. Result

The Seven Tag Roster is the common identification core of a PGN game.

Event

Name of tournament/match/event.

Site

Location.

Date

Starting date of game, using PGN date conventions.

Round

Round ordinal/identifier.

White / Black

Player names.

Result

One of:

• 1-0;
• 0-1;
• 1/2-1/2;
• *.

Result tag and termination marker

Canonical PGN requires:

• Result tag;
• final movetext termination marker

to agree.

Example:

[Result "1-0"]

1. e4 e5 ... 1-0

Incorrect canonical pair:

[Result "1-0"]

... 1/2-1/2

PGN stores the result twice in two different structural locations, and canonical export keeps them consistent.

Supplemental tags

PGN supports more metadata than the STR.

Representative tags:

• WhiteElo;
• BlackElo;
• ECO;
• Opening;
• Variation;
• SetUp;
• FEN;
• TimeControl;
• Annotator;
• PlyCount;
• Termination.

The reader does not need to memorize every available or vendor-specific tag.

STR is the common core; supplemental tags extend context.

ECO / Opening / Variation metadata

Example:

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

These tags describe opening classification/name metadata.

These fields represent classification metadata. Whether a particular opening label is theoretically precise, current or strategically useful is a separate opening-theory question.

Ratings

Examples:

[WhiteElo "2500"]
[BlackElo "2475"]

These are metadata about players at the represented event/game.

They are not:

• engine evaluations;
• puzzle ratings;
• current live ratings unless the source says so.

Non-standard starting positions

Games that do not start from the ordinary initial array use:

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

Example:

[SetUp "1"]
[FEN "8/8/3k4/8/3K4/8/8/8 w - - 0 1"]

The FEN defines the starting position.

PGN can represent a game beginning from a supplied position, not only from move 1 of the standard start.

PGN movetext

Movetext can contain:

• move number indications;
• SAN moves;
• NAGs;
• RAVs;
• comments;
• final termination marker.

Example:

1. e4 e5 2. Nf3 Nc6 3. Bb5 {Main line.} a6 $1
(3... Nf6 4. O-O) 4. Ba4 1/2-1/2

Not every PGN is annotated.

Comments in PGN

Two comment styles appear in the original specification.

Brace comment

{This is a comment.}

Semicolon comment

; comment until end of line

Brace comments are the better reader-facing default for portable inline authored examples.

Brace comments do not nest

Do not place:

• nested { ... { ... } ... }

comments and expect standard recursive behavior.

Use RAV parentheses for move variations, not nested braces.

Tag-pair syntax in practice

A PGN tag pair has a simple visible shape:

[TagName "Tag value"]

The brackets, tag name and quoted string are structural data, not decorative punctuation. A reliable exporter must also handle escaping inside string values correctly rather than breaking the record when a value contains special characters.

Unknown or unavailable metadata is often represented with conventional placeholder values such as ?, while an incompletely known date can use question marks in the date field. The important point is to distinguish unknown data from an empty or malformed tag.

The Seven Tag Roster as an archival spine

The Seven Tag Roster gives a common minimum identity for a game:

• where and in what event it occurred;
• when it occurred;
• which round;
• who played White and Black;
• what the result was.

That does not mean seven tags are enough for every modern workflow. Ratings, time control, opening classification, annotator information and other metadata can be valuable, but they extend rather than replace the common core.

Metadata is not movetext

A recurring data-modeling mistake is to force game facts into the move sequence.

Examples:

• player ratings belong in tags, not SAN tokens;
• opening classification belongs in metadata, not a fabricated move comment unless editorially desired;
• the game result belongs both in the Result tag and as the movetext termination marker;
• a non-standard initial position belongs in SetUp/FEN, not in an invented sequence of moves from the normal start.

Keeping these layers separate makes PGN easier to validate, search and exchange.

PGN as a container around SAN

PGN does not replace SAN. It contains SAN movetext inside a larger game record.

A useful mental model is:

metadata tags + movetext structure + SAN moves + annotations + termination

That is why a file containing only 1. e4 e5 2. Nf3 is readable chess notation but not a complete archival PGN record in the same sense as a tagged game object.

Frequently asked questions

What is the difference between PGN and SAN?

SAN represents individual moves. PGN is a game-record format that uses SAN inside movetext and adds metadata, move numbers, variations, comments, annotations and a result marker.

Does every PGN need opening and rating tags?

No. They are supplemental metadata. The classic common core is the Seven Tag Roster, while real databases may include many additional tags.

Why is the result stored twice?

The Result tag is metadata and the termination marker ends the movetext. A clean export keeps them consistent so the game identity and the move sequence agree.

Key takeaways

PGN structure:

• tags;
• blank separation;
• movetext;
• termination.

Core metadata:

• Seven Tag Roster.

Supplemental tags can encode:

• ratings;
• opening metadata;
• time control;
• alternate start;
• annotation context.

Critical rule:

• Result tag and termination marker agree in canonical export.