Chess has eleven separate rules in the FIDE Laws of Chess. Every legal move falls under one of them — how each piece moves, when castling is allowed, what counts as en passant, when a draw is automatic. Implementations that get all eleven right exist in many programming languages, in many sizes, but the vast majority weigh somewhere between five and fifty kilobytes. The question we set ourselves was simpler than it sounds: how small can a complete one get, in plain JavaScript, with no external libraries, no build step, and no game-engine framework?

The answer, after months of iteration, is 2048 bytes — including the visual layer that makes the board align in any browser. The bare engine, without the visual polish, is 1996 bytes. This essay is the story of how the byte count came down, what we sacrificed, what we kept, and what we tried that didn't work.

It is also, in places, an argument: that some choices that look like obvious wins (a bitboard, a 0x88 mailbox, a clever input parser) cost more bytes than they save in JavaScript, and that some choices that look like obvious losses (text input, a serif font, an alert box for results) turn out to be free.

The cheapest user interface in a browser is the one already there. The prompt() dialog needs no HTML, no CSS, no event listeners, no DOM access at all — you call it with a string, the browser puts up a modal, and when the user clicks OK you get a string back. The entire interaction is two function calls: one to show the board (which is also the input dialog), one to display the result (alert).

Compare this to the alternative. A <canvas> board would need getContext('2d'), calls to fillRect per square, event listeners for clicks, coordinate-to-square math, and a redraw routine after every move. Even at its most aggressive golfing, that overhead is several hundred bytes. A <table> board (the path Toledo took) is cheaper than canvas but still asks for innerHTML manipulation, onclick handlers, and a render function that walks 64 cells.

The prompt() route trades visual elegance for zero cost. The board renders as text inside the dialog. Input is typed, not clicked. Everything blocks while the dialog is open — including the page itself, which is why the clock cannot tick visibly between moves. We accepted that trade.

A side benefit emerged after the fact: prompt() works everywhere. Every smartphone, every smart TV with a browser, every e-reader. There is no canvas to fail to render, no touch-versus-click ambiguity. You type your move and press OK.

Toledo's famous JS chess implementations all play against you. So do most of the well-known size-records: nanochess, micromax, the various 1K demos. They include a search routine — usually alpha-beta minimax to a shallow depth — that plays one side automatically. This adds value but it also adds bytes, often several hundred of them.

We made a different decision early on. The rules of chess are interesting in their own right; the question of whether this engine can mate that position is a separate, much larger problem. By focusing on the rules alone — making sure every legal move is accepted, every illegal one rejected, every termination correctly recognized — we kept the engine's purpose narrow. Two humans take turns. The program is the referee.

This freed somewhere between 500 and 1000 bytes, depending on how aggressively an AI is golfed. The trade is the obvious one: you need a friend, or you play both sides yourself. In return, every byte of the engine is in service of FIDE compliance, not in service of "what move would a computer play here."

The board lives in a single variable, s, which is an array of 64 single-character strings. Index 0 is a8, index 7 is h8, index 56 is a1, index 63 is h1. A white queen is 'Q', a black knight is 'n', an empty square is '_'. Case carries color: uppercase white, lowercase black.

The initial setup is built from a template literal:

The spread operator turns the 64-character string into an array of 64 single characters. The ${_.repeat(32)} in the middle is the 32 empty squares between the pawn ranks. The variable _ is set to the literal string '_' just above; that one-character variable name will be reused throughout the engine to mean "empty square."

This choice has consequences. Coordinates work out as x = i % 8, y = i >> 3. Bounds checks become natural 0 ≤ i < 64. To test color, p < 'a' tells us if a piece is white (uppercase letters all sort below lowercase in ASCII). To convert to uppercase for piece-type lookup, p.toUpperCase().

A more computer science-flavored alternative would be a 0x88 mailbox — a 128-element array where the high nibble encodes the rank and the low nibble encodes the file, with a single bit-test (i & 0x88) to check if you've walked off the board. This is what serious chess programs in C use, and the technique is genuinely elegant.

We tried it. The result was +795 bytes. Why? Because 0x88 wins by enabling fast directional iteration (walk a bishop diagonally until you hit the edge or a piece), and our move generator doesn't iterate directionally. It scans the whole board every time. So we pay the cost of the larger array, the cost of every (i & 0x88) guard, and the cost of explicit direction arrays — without using the speed advantage that justifies all of that. The technique is right for C and asm. It is wrong for our JavaScript.

The move generator G(d) returns the list of squares the piece on square d can legally move to. It works by looking at every other square on the board and asking, for each one, "can this piece reach there?" Sixty-three questions per move generation. It is, by the standards of serious chess engines, criminally slow.

It is also criminally short. The entire function fits in around 350 bytes, which is less than half of what a directional generator would cost in JavaScript. The reason is that all six piece types share the same outer loop and the same target-square evaluation. The logic of what makes a move legal differs only in a single chained ternary expression at the heart of the loop:

D and H are the absolute differences in file and rank. A knight legal-move check is "the product of those differences is 2" (because a knight's move is always 1×2 or 2×1). A king's is "both differences are less than 2." A bishop is "both differences are equal and the path is clear." A rook is "one of the differences is zero and the path is clear." A queen is "either of those." A pawn has its own clause, where direction matters.

The C(d, i) function — "is the path from d to i clear of obstructions?" — is itself just six lines, walking the line one step at a time and checking each intermediate square.

Speed doesn't matter here. The generator is called only when a human enters a move; there is no search tree, no millions-of-positions-per-second requirement. A move is generated, validated, and applied in well under a millisecond, and the player is the bottleneck anyway. Trading speed for size is the entire point.

Check, checkmate, and stalemate all share a single primitive: is a given square attacked by a given color? The function that answers it is called L, and it is the only function in the engine longer than a screenful. It returns 1 if the answer is yes.

From here, everything else is composition. J(W) — "is the side W's king in check?" — finds the king (s.indexOf("kK"[+W])) and asks L if it's attacked by the other color. That's the entire check detector. Two function calls.

Checkmate is "the king is in check and the side has no legal moves." Stalemate is "the king is not in check and the side has no legal moves." We test these together with a single scan over the 64 squares: walk every square, ask the move generator if the piece there (if it belongs to the side to move) has any legal moves. If after the full scan no legal moves were found, the position is terminal — and then a single call to J decides whether it's mate or stalemate. The whole thing fits in one line.

The move generator does not return "pseudo-legal" moves; it returns only moves that leave the moving side's king out of check. It enforces this by simulating each candidate move on a temporary copy of the board, calling J, and discarding the candidate if the king ends up in check. This is, again, slow by competitive standards. Generating 20 candidates means cloning the board 20 times. But the clone is cheap (a single s.slice()), and at human reaction time scales it is invisible.

The function M(f, t, p='Q') applies a move from square f to square t, with an optional promotion piece p. It handles regular moves, captures, en passant, castling, promotion, and all the bookkeeping that updates castling rights, the en passant target square, and the halfmove counter — in roughly twelve lines.

The trick is sequencing. Capture-and-place runs first as the common case: s[t] = s[f]; s[f] = '_'. Then five small clauses handle the special cases, each guarded by a check on the moving piece's type:

Notice the order: the en passant capture-removal happens before the piece moves into the en passant square, because we need the captured pawn's position relative to the source. The castling rights update happens after the king move, because we need to know who moved.

The R object is a tiny lookup table from rook starting square to the castling-rights bit it represents. When a rook moves or is captured, the relevant bit clears. The whole table is four entries: {0:8, 7:4, 56:2, 63:1}. Four entries, four bytes of meaning each.

Promotion deserves a note. When the input is a four-character move (a7a8), there's no promotion character, and p defaults to 'Q'. When the input is five characters (a7a8N), the fifth character is used as the promotion type — but only if it matches Q, R, B, or N (any case). The matching is done by a regex (/[QRBN]/i) on the way in; anything else silently becomes Q. So a7a8K and a7a85 both become a queen promotion. We made this choice for input forgiveness, but it has a side effect: an old bug where players in a hurry typed garbage characters became invisible. The game keeps going.

The FIDE rules give three automatic draw conditions beyond stalemate: the 50-move rule, threefold repetition, and dead position (insufficient mating material). Each of them is implemented with a different golf trick.

The 50-move rule is a single integer, n, that counts halfmoves since the last pawn move or capture. It's incremented in M on every move that doesn't reset it, and the main loop checks n > 99 before each prompt. When the counter exceeds 99 (i.e., 50 full moves without progress), the result is set to D! and the loop breaks. The bookkeeping is two characters per relevant decision.

Threefold repetition needs a position hash, and a way to count how often each hash has been seen. We use an object, P, with the joined board string plus the side-to-move, en passant target, and castling rights as the key. The trick is the increment expression:

B is the board joined into a string. The +=[t,e,o] appends the comma-joined string version of the three state variables (template literals would have worked but cost more bytes). -~x is JavaScript golf shorthand for x + 1, with the convenient property that -~undefined is 1 — so the first time we see a position the count starts correctly. The right side of the assignment is the new count; we compare to 2 because three occurrences means we've seen it twice before this one.

Dead position is the trickiest of the three because FIDE's definition is awkward: K vs K, K+minor vs K, and K+B vs K+B with same-colored bishops are dead. We test this with two regular expressions over the joined board string:

The first half catches "only kings and bishops, all bishops on the same color." The bishop color is computed from its position with (k ^ k>>3) & 1 — an old trick that gives 0 or 1 depending on the square's color parity. The second half catches "only kings and at most one knight." This is not every dead position FIDE recognizes (K+B vs K+N can be dead in some configurations, for example), but it covers the common cases without bloating the engine.

Each side starts with 900 seconds. The clock is two integers, u and v, decremented after each move by the number of seconds spent in the prompt dialog. The dialog blocks JavaScript execution, so the time the dialog was open is the time the player took to think.

Originally we computed elapsed time with (new Date - d + 500) / 1e3 | 0 — the +500 rounds to the nearest second. After a Gemini-led optimization pass, we dropped the +500: (new Date - d) / 1e3 | 0. This floors instead of rounding. Each move now consumes at most one second less than it used to.

Two reasons. First, FIDE specifies floor truncation for displayed clocks anyway, not round-to-nearest. Second, the saving (four bytes per occurrence, and the function is used twice) was real. The behavioral change is tiny and biased in the player's favor: across a long game, a player might recover something like ten seconds total, which is within the noise of real chess timekeeping.

The clock also doesn't tick visibly. The prompt blocks the JavaScript thread, so any setInterval-driven UI would queue up updates and only flush them when the prompt closed. The clock value shown at the top of each prompt is the value at the moment the prompt opened; the elapsed time of your current think is subtracted on submit. Functionally equivalent to a wall clock; visually less satisfying. We accepted that.

The bare engine renders the board with ordinary ASCII letters. In a typical browser's prompt dialog, those letters are drawn in the system UI font — which is proportional. Narrow letters like r and i take less horizontal space than wide ones like Q and M. Columns drift. The board looks like a misaligned grid.

The fix is one of the small joys of Unicode. The range U+FF21 to U+FF5A is a parallel ASCII alphabet of "fullwidth" letters: Ｒ Ｎ Ｂ Ｑ Ｋ instead of R N B Q K. They're designed to occupy the same horizontal space as a CJK character — which means, on systems with the standard CJK font fallback (i.e., basically every modern browser), they render monospaced.

The trick is that every ASCII printable character has a fullwidth counterpart at exactly code + 65248. We don't need a lookup table:

The whole UI upgrade is this one line, plus changing W:${u} B:${v} to W:${u}s B:${v}s (the s suffix telling the user the unit is seconds). The total cost is 52 bytes. The result is a board that lines up in every browser the engine runs in.

The deployed page index.html uses the fullwidth UI layer. In the catalog, every variant comes in both UI states — the file with no _U suffix uses plain ASCII rendering, the one with _U uses fullwidth glyphs. The plain-ASCII versions are what gets compared in size against other golf chess implementations; the UI-on versions exist for anyone who wants the cleanest browser experience at a 50-byte premium.

Six independent feature flags, each present or absent. Three describe the engine's capabilities: T (the clock and 50-move counter), M (the FIDE move set: castling, en passant, two-square pawn advance), P (choosable promotion). One more, D, adds the two early-claim draw detectors (threefold repetition and dead position) — but only on top of the full T+M+P stack. Then two presentation flags: S (showON/showOFF — whether the terminal result is alerted) and U (uiON/uiOFF — whether the board uses fullwidth glyphs and the timer gets a s suffix).

The naming on disk follows the pattern index_[L2-flags][_D][_S][_U].html. Examples: index_TMP is the full move-set engine, silent, plain ASCII. index_TMP_D_SU is the full FIDE engine with the terminal alert and the fullwidth UI — identical in content to the deployed index.html. The most primitive variant — no L2 features, no S, no U — is the lone file labeled index_L1.html; all other L1-level files (with only S/U flags) drop the L1 prefix entirely, becoming just index_S, index_U, index_SU.

Materializing every legal combination as a separate file gives thirty-six variants. Not every combination is interesting; some are useful only as intermediate proof points (what does adding the timer alone cost? what does adding promotion choice without the rest of the move set cost?). But all thirty-six are tested, and the catalog lets a reader see exactly how each FIDE rule and each presentation layer adds bytes by comparing same-flag pairs across the table.

For example: index_TM is 1673 bytes; index_TMP is 1716 bytes. The difference is just the promotion-choice handling: 43 bytes. index_L1 is 1072 bytes; index_TMP is 1716. The 644-byte difference is the cost of clock + full FIDE move handling on top of the bare engine. index_TMP_D_S is 1996; index_TMP_D_SU is 2048. The 52-byte difference is the entire UI polish layer.

The catalog is generated by a single HTML file, version_generator.html, which contains a parameterized build function. This is how we make sure the generator stays the canonical source: any optimization gets applied once to the generator and propagates to all thirty-six variants at the next regen.

The first working version was around 3,000 bytes. Most of the bulk was readable code: meaningful variable names, explicit destructuring, comments. The shrinkage proceeded in passes, each finding a different category of waste.

Single-character variables came first, the easy win in any code-golf project. board became s; turn became t; halfMoveCount became n. Functions were declared with arrow syntax and default parameters: w=p=>p<'a' instead of a function declaration. Math methods were aliased: A=Math.abs, S=Math.sign. Each alias is worth it after about three uses.

Then came the structural choices: combining make and unmake by snapshot-and-restore instead of inverse moves; consolidating six piece-type clauses into one chained ternary; collapsing the input parser into the same arithmetic step (63 - 8 * i[1] + i.charCodeAt() % 32, a clever map from "a8"-style notation to square index, courtesy of an early Gemini suggestion).

The final round was a six-trick batch suggested in collaboration with Gemini. Each trick was tiny on its own and all but invisible in isolation, but they totaled −312 bytes across the eighteen variants:

1. A coordinate parser function K=c=>63-8*i[c+1]+i.charCodeAt(c)%32 replacing two near-duplicate parsing expressions.
2. Floor instead of round for the clock decrement: +500 removed.
3. The board-render regex /(. ){8}/g tightened to /.{16}/g (both match the same thing for our board, but the second is shorter).
4. Castling direction check rewritten from X-x<-1 to x-X>1.
5. Promotion edge check rewritten from !(Y%7) to Y%7<1.
6. En passant target check rewritten from A(Y-y)==2 to A(Y-y)>1 (safe because the move generator already restricts pawn advances to ≤2).

None of these changed the engine's behavior in any way that matters. All thirty-six variants regenerate cleanly, and the test suite (414 deep tests, 36 perft, 90 crash, 5 mirror-parity) still passes 100%.

Two ideas looked promising and turned out wrong; we record them here because the wrong-headedness is part of the story.

0x88 mailbox. Discussed in §04. We wrote a complete 0x88 engine as an experiment, expecting savings of 30–80 bytes. It came in at 2791 bytes, nearly 800 over the existing one. The technique is right for languages that make array literals and tight loops cheap (C, assembly). JavaScript pays for both. The experiment is preserved in the repository as a teaching artifact.

Bitboards with BigInt. Briefly considered, never implemented. The cost analysis was enough to kill it: every 1n << 8n in place of 1 << 8, every BigInt literal carrying an n suffix, every comparison needing parentheses around the BigInt arithmetic. The precomputed attack tables alone would add several hundred bytes. A representation that's a clear win in C ends up a clear loss in JS.

Direct alphabets. We tried Mathematical Bold (𝐊 𝐐 𝐑), Mathematical Sans-Serif (𝖪 𝖰 𝖱), Math Sans-Serif Bold (𝗞 𝗤 𝗥), and Math Monospace (𝙺 𝚀 𝚁) as alternatives to fullwidth. They all worked, but at +94 bytes each instead of fullwidth's +78, because they're 4-byte UTF-8 surrogate pairs and need extra spread-and-index handling. Fullwidth's BMP encoding made it the right choice.

A random-move AI. An afternoon's experiment: drop in Math.random() over the legal moves list and have the engine play one side. About 137 extra bytes. It worked, but it played at the level of someone who'd just learned the rules — perhaps 250 ELO. Toledo's actual AI plays around 1200. The point of an AI is that it should be better than blind chance, and we couldn't afford alpha-beta. We pulled it.

Golfed code is easy to break. A single misplaced operator can turn a legal move into a crash, or worse, into a wrong-but-plausible behavior that passes casual play but corrupts a tournament. We knew from the start that we needed a way to verify the engine systematically.

The solution is test_helper.html, which contains two independent implementations of the rules and runs them in parallel. The first is a reference engine: a clean, readable, deliberately uncompressed implementation of FIDE rules, designed to be obviously correct. The second is a mirror engine: a structural port of the golfed engine that maintains the same control flow but uses readable variable names. The mirror is supposed to behave identically to the golfed motor on every input.

The test suite plays full games through both engines and asserts after every move that their states agree: piece positions, castling rights, en passant target, halfmove counter, repetition map. If they ever disagree, something in the golfed engine is wrong.

This is supplemented by category-specific tests: 414 deep tests across four motor profiles covering each FIDE rule in detail; 36 perft tests at depth 3 across all variants; 90 crash tests with adversarial input; 5 mirror-parity tests for the 50-move and threefold draw edge cases. The result is unambiguous: every release passes all 545 tests.

In the current state of the field, no public JavaScript chess implementation handles all eleven FIDE rules in fewer bytes. Toledo's various JS versions are between 1024 and 2299 bytes; the smaller ones omit castling, en passant, or promotion choice; the larger ones omit threefold repetition and dead position. Our 1996-byte bare engine handles all eleven, and the 2048-byte deployed page does so with a properly aligned visual layer.

This is a small claim, defended by a narrow niche. If Toledo (or someone of comparable skill) refactored their AI-based engine to be a human-vs-human prompt-based engine with all eleven FIDE rules, the result would probably land around 1500 bytes — well below us. The savings would come from sharing the move-generator code between move execution and AI search in clever ways we don't need to consider.

We are aware of this and we accept it. Our claim is not "no one can beat this." It's "no one has, and the gap to anyone who might is at least one substantial refactor away." Whether anyone takes that on is up to them.

The other axis where we might lose: bytes are not the only thing. A Toledo engine plays. We don't. For someone whose primary use case is "I want to play chess against a computer at lunch," we are the wrong tool. For someone whose primary use case is "I want to look at a complete, audited, FIDE-compliant chess implementation that's small enough to read in one sitting," we are, at present, the smallest such thing.

Three things we did not anticipate at the start, and learned along the way.

One. Optimization choices that look like they're about bytes are often about behavior. Removing +500 from the clock saved four bytes per use, but it also changed when the clock rounded — and the new behavior turned out to match FIDE's specification better than the old one. The byte-savers were often hiding correctness improvements.

Two. JavaScript is unusually well-suited to compact rule-based programs and unusually poorly suited to compact arithmetic-heavy ones. The string-array board, the regex draw detector, the template-literal init — these are all idioms native to JavaScript that have no direct equivalent in C. They each save dozens of bytes. Whereas the bitboards and 0x88 mailboxes that are the gold standard in C cost more bytes in JavaScript, not fewer. Language-aware design matters.

Three. The niche we ended up occupying — fully FIDE-compliant, human-vs-human, prompt-based chess in plain JavaScript — was not the niche we set out for. We set out to write a small chess engine. The niche emerged from the cumulative weight of small honest decisions: prompt because it was free, two-player because we didn't need an AI, eleven rules because we'd come this far. None of it was strategic. All of it became strategic in retrospect.

What we have, at the end, is a 2048-byte single HTML file that plays a complete FIDE-legal game of chess in any browser, with no dependencies, no build step, and a worked test suite that catches every regression. It is not the most impressive piece of software anyone has ever written. It is, in its small and specific way, exactly the piece of software we wanted to write.

Open index.html · Read the rules in manual.html · Browse the catalog in the repository.