When a diagram is created using FENs, and one tries to add variations that continue from the given position, the viewer only works if the starting move number is between 1 to 9 (included). For instance, both following examples work: (when copy pasting these to test, make sure to have the 5 spaces before each line)

Using the mover number indicated in the FEN:

 [title "starting at a move number <10"]
 [fen "rnbq1rk1/pp2bppp/4pn2/2pp4/2PP1B2/2N1PN2/PP3PPP/R2QKB1R w KQ - 0 7"]


Using any number as long as <10:

 [title "starting at a move number <10"]
 [fen "rnbq1rk1/pp2bppp/4pn2/2pp4/2PP1B2/2N1PN2/PP3PPP/R2QKB1R w KQ - 0 7"]


However, as soon as the starting move is a 2-digit number it no longer renders the diagram, for instance:

 [title "starting at move number 10 or above"]
 [fen "rnbq1rk1/pp2bppp/4pn2/2pp4/2PP1B2/2N1PN2/PP3PPP/R2QKB1R w KQ - 0 7"]


There has been related discussions before, e.g. here, but I haven't found any posts that pertain to this particular behaviour of the diagram viewer.

  • Is there possibly a workaround, other than using the full game PGN + [startply ""], to create a diagram with a starting move number greater than 9?

  • This may not ultimately be a bug, maybe the viewer is designed to only consider 1-digit starting move numbers, and fails to render when not satisfied. Maybe @Andrew knows more about this (?).

1 Answer 1


This part of the fen string "w Kq - 0 7" is copy and pasted between posts (not least by me) often without understanding what the different elements mean.

The "w" means it is white's move (and is important if adding moves)
The "Kq" means white can still legally castle king's side and black queen's side.
The "-" means en passant is not possible
The "0" means there have been zero moves since the last capture or pawn move (used for the 50 move rule) and
The "7" means that there have been 7 full moves.

That means that strictly speaking this fen should also not work and the fact that it is does is also a bug

 [title "starting at a move number <10"]
 [fen "rnbq1rk1/pp2bppp/4pn2/2pp4/2PP1B2/2N1PN2/PP3PPP/R2QKB1R w KQ - 0 7"]


I have never come across the working part of the bug you report because when I have tried it I have always used a move start number greater than 9. The work around I use is to ignore the designated use of the full move counter and always code like this:

 [title "starting at a move number <10"]
 [fen "rnbq1rk1/pp2bppp/4pn2/2pp4/2PP1B2/2N1PN2/PP3PPP/R2QKB1R w KQ - 0 1"]


It has the benefit of working while only offending the pedants and purists (like myself) who know what the stuff at the end of the fen string is supposed to mean.

  • You can just copy/paste the examples to recreate the bug for yourself, and make sure you get same output as I do. Yes starting the move number from 1. irrespective of the actual move number is what I had always done because of the described issue.
    – Ellie
    Commented Feb 1, 2020 at 22:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .