FreeToGenerate.com

Validates a FEN field by field, draws the position, and says which of the two en passant conventions the string follows — because the standard and the most-used library disagree. Nothing is uploaded.

Six fields separated by spaces: piece placement, side to move, castling rights, en passant target, halfmove clock, fullmove number.

Try one:

What the parser found

  • The two conventions write this position differently, so a tool comparing FEN strings would call these two records different positions. That is the practical cost: string equality is not position equality.

  • The en passant square is named but no pawn can use it. The PGN standard requires exactly this — it says the square is given if and only if the last move was a two-square pawn advance, whether or not anyone can capture.

The position

Drawn from the first field alone. A FEN records a position, not a game, so nothing here knows how the pieces got there.

The six fields

FieldValueMeans
Piece placementrnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNRRanks from the eighth down to the first, files a to h, digits counting empty squares.
Side to moveBlackWhose turn it is.
Castling rightsKQkqWhich castles remain available, as rights rather than as legal moves right now.
En passant targete3The square a pawn just passed over, if one did.
Halfmove clock0Moves since the last capture or pawn move, for the fifty-move rule.
Fullmove number1Starts at one and goes up after each of Black's moves.

Which convention this FEN follows

The PGN standard

This FEN names an en passant square that no pawn can actually capture. Only a writer following the PGN standard produces that, because the other convention would have written a dash. This is the one case that identifies a convention for certain.

The same position, both ways

PGN standard — always record the square
rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
Only when capturable — what most libraries emit
rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1

Everything here runs in your browser. Nothing is uploaded.

Also available in: Español · Português · Français · العربية

FEN parser: validate a chess position, and see which convention it uses

Paste a FEN to check every field, draw the board, and find out whether the en passant square gives away which tool wrote it.

What a FEN is

Forsyth-Edwards Notation packs a whole chess position into a single line of text. It has six fields separated by spaces: where the pieces are, whose turn it is, which castles are still available, the en passant target square, how many halfmoves have passed since the last capture or pawn move, and the move number. The starting position is rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1.

The placement field reads from the eighth rank down to the first and from the a-file to the h-file, using letters for pieces — uppercase for White — and digits for runs of empty squares. That ordering is why a FEN looks upside down compared with how you would type a board out yourself: it starts at Black's back rank.

A FEN describes a position and nothing else. It does not record the moves that led there, which turns out to matter more than it sounds, because one of the six fields is about the previous move.

How to use it

  1. Paste a FEN, or pick a sample. The samples include the standard's own example after 1. e4, the starting position, an en passant square that can genuinely be captured, one that only looks capturable, and a string with several things wrong in it.
  2. Read the field table and the board. Every field is shown with its value and what it means. Anything unreadable is reported as an error; anything readable but impossible — a pawn on the back rank, a castling right with no rook — is a warning rather than a rejection.
  3. Check the convention verdict. If the en passant square is named but nobody can capture it, the FEN was written by something following the PGN standard, and the tool prints both spellings so you can see what the other convention would have produced.

The en passant field, where two conventions disagree

The PGN standard is explicit about the fourth field. An en passant target square, it says, is given if and only if the last move was a pawn advance of two squares — and therefore the field may have a square name even if there is no pawn of the opposing side that may immediately execute the en passant capture. The rule is about what just happened, not about what is now possible.

The standard then demonstrates that twice in its own worked examples. After 1. e4 it prints a FEN ending b KQkq e3 0 1, and Black has no pawn within reach of e3. After 1... c5 it prints w KQkq c6 0 2, and White's only pawn is on e4, nowhere near c6. Both record a square that cannot be used.

Most software does the opposite. chess.js, the library most web chess tools are built on, writes the square only when the capture is actually legal — its own source comment says it prints the en passant square only if en passant is a valid move, with the pawn present and the capture not pinned. It offers an option to force the standard's behaviour, but that is not the default.

So one position has two spellings, differing in a single field, and neither is wrong. The practical cost is that FEN string equality stops being position equality: deduplicating a game collection by FEN, looking a position up in an opening book, or detecting a threefold repetition by comparing strings will all treat those two records as different positions. If you have ever seen a position that should have matched and did not, this is a good first thing to check.

What this can and cannot tell you

The convention verdict has three states and only one of them is a real answer. A named square that nobody can capture identifies the PGN standard for certain, because no capturable-only writer would ever emit it. A named square that can be captured tells you nothing, since both conventions write it. And a dash tells you nothing either — it could mean no pawn advanced two squares, or that one did and this writer omits the square. A FEN does not record the previous move, so that question cannot be settled from the string alone, and the tool says so rather than guessing.

Deciding whether the capture is genuinely available needs the whole board rather than the two squares beside the pawn. The capturing pawn can be pinned against its own king, and there is a rarer case where the capturing pawn and the captured pawn both leave the same rank at once and expose the king to a rook along it. This page plays the capture out and checks whether the king ends up attacked, which is the same test the libraries perform — an adjacency check would get both of those wrong.

Validation stops short of legality. The tool checks that the six fields are well formed and flags positions that could not arise in a game — no king, two kings, a pawn on the first rank, a castling right with no rook behind it — but it does not attempt to prove a position reachable, which is a much harder question than it looks. A FEN can be perfectly well formed and describe something no game could produce.

Two smaller things. Castling rights are rights, not legal moves: a FEN can say KQkq while the king is currently in check and cannot castle at all. And the halfmove clock is information about the game rather than the position, so two identical-looking boards with different clocks are different FENs and, for repetition purposes, genuinely different records.

Why is it free?

Parsing a line of text and drawing eight rows of squares runs in your browser. There is no server in the loop, so there is nothing to bill for and no account to create.

Nothing is uploaded. Reload the page and it has forgotten the position.