By Silent Engineer · Updated 05 October 2026
How Spliinter validates a word
Word checks happen on the server, not just in the page. This keeps the dictionary, letter rules, round deadline and scoring consistent for everyone in a room.
What happens when you submit
The browser sends the typed word to the game server over Socket.IO. The server first checks that the player is in a room and that the room is in the playing phase and still before its deadline. If play is over, the word is rejected without entering the round results.
For an active round, the server normalizes the text to lowercase and trims surrounding whitespace. It rejects empty input, input longer than 40 characters, and characters outside the English letters a to z. It then checks the minimum length, base-word exclusion, available letter counts and dictionary membership. Finally, it prevents the same player from adding the same accepted word twice in one round.
Count letters, not just their presence
The validator builds a count for each letter in the base word, then walks the candidate answer. A candidate is invalid if it asks for a letter that is absent or uses more copies than the base contains. That is why LOCAL fails for CHOCOLATE: there is an L, but only one, and LOCAL needs two.
A simplified version of that inventory check looks like this:
function fitsInventory(word, baseWord) {
const available = new Map();
for (const letter of baseWord) {
available.set(letter, (available.get(letter) || 0) + 1);
}
for (const letter of word) {
const remaining = available.get(letter) || 0;
if (remaining === 0) return false;
available.set(letter, remaining - 1);
}
return true;
}The production rule code uses the same idea: count the base letters once for the check, then reduce the remaining count as each answer letter is consumed.
The dictionary is loaded at startup
At process startup, Spliinter reads the word file exposed by the word-list npm package, normalizes entries to lowercase, removes empty lines and duplicates, and builds an in-memory set for membership checks. The implementation adds three explicit entries to that set. The same loaded set is used by every room until the server restarts.
A quick dictionary lookup cannot decide whether an answer is fair by itself: the server checks the base word’s inventory first. A word in the dictionary may still be rejected because it is too short, is the base word, or requires unavailable letters. There is no separate player-selected dictionary or browser-side exception list.
Why the browser is not the referee
The browser provides the tiles, input field and countdown display, but the server owns the game state. It sets the round end time and validates submitted words. A browser clock can render a convenient countdown using server timestamps, but changing a local display does not extend the server’s deadline.
The server also keeps each player’s current words private from other players during the round. Other players receive a word count, not a copy of those submissions. This prevents the results page from being determined by what another browser chooses to show.
Duplicates are decided after the round
Each player’s accepted words are stored in a set for that round, so one player cannot score the same word twice. When the timer ends, the server counts how many different players submitted each word. A word found by exactly one player earns one point; a word found by two or more players is marked cancelled for everyone who found it.
The server then calculates round scores, assigns medals to positive scores in rank order, updates game totals and sends the reveal. The same word may be tried again in another round because the duplicate comparison is scoped to a single round.
Reconnection and in-memory state
When a player joins, the server creates an opaque reconnect token. The browser keeps the token with the username and room information in the current tab’s session storage. After a refresh or a temporary network interruption, the browser can present that token to reattach to the matching player while the room and server process still exist.
The token is not a permanent account and is not a backup. Room state—including words and scores—lives in server memory. A room is removed after it has been empty for the configured delay, and a server restart clears all rooms immediately. A reconnect token cannot restore state that no longer exists.
What is measured
The server does not write rejected-word rankings or a history of submitted word text to a database. Optional Google Analytics events can count actions such as word submissions after analytics consent is granted; the event does not include the word, username or room code. See the Privacy Policy for the browser-storage and analytics details.
Related guides
Play a round, review letter-count traps, read the player rules, or visit the About page for base-word selection details.