A server seed is the secret number a provably fair site locks in before you open a box, and it is the single ingredient that decides which item you pull. The site shows you a scrambled fingerprint of it up front, keeps the real value hidden while you play, then reveals it afterward so you can prove the result was set in advance and not changed. That commit-then-reveal step is the whole idea, and once you have seen it work you can check any pull yourself.
The sealed envelope idea
The easiest way to picture a server seed is a sealed envelope. Before you open a box, the site writes its secret number on a card, seals it in an envelope, and hands you a tamper-proof stamp of that sealed envelope. You cannot read the card yet, but the stamp proves the card existed and has not been swapped. When the round is over, the site opens the envelope and shows you the card. You check that it matches the stamp from the start, and now you know the answer was decided before you ever clicked.
In real terms, the card is the server seed: a long random string, usually 64 hexadecimal characters. The stamp is a SHA-256 hash of that string. A hash is a one-way fingerprint. It is easy to go from the seed to its hash, and effectively impossible to go backward from the hash to the seed. That one-way property is what lets a site prove it committed to a value without revealing it while you play.
Why you only see the hash first
If the site showed you the raw server seed before your pull, you could compute the result in advance, and so could anyone who saw it. If it never revealed the seed at all, you would have to take the outcome on trust. The hash solves both problems at once. You get the fingerprint before you play, so the site is locked in, and you get the real seed after, so you can check it. The site cannot show you one seed up front and quietly use a different one, because the different seed would not match the fingerprint you already hold.
This is why a hashed server seed on its own looks like meaningless gibberish, for example a line like 42097f7d1b1a28ee54a3da3a6f6be1d168efdcf54332af79f59c1db6231158c1. That is the stamp. The card that produced it stays hidden until your seeds rotate.
How the server seed decides your pull
The server seed does not act alone. Your outcome comes from three inputs run through a keyed hash function:
- The server seed, the site's secret, committed in advance.
- Your client seed, a value tied to your account that you can change whenever you want.
- The nonce, a play count that ticks up by one every time you open, so each pull in a sequence is different.
Those get combined and run through HMAC, a standard keyed-hash function, and the resulting hex is turned into a number that maps to your item. Here is a worked example using one real published scheme, so you can see there is no magic in it:
server seed (revealed after): 8f2a1c9e4b7d0a63f5e8c2b1a4d7906e3c8b5f2a1e9d4c7b0a6f3e2d1c8b5a49
client seed: player-chosen-seed
nonce (play count): 42
HMAC-SHA256(key = server seed, message = "player-chosen-seed:42")
= 7f7c47d46f21aa75eebcad01075ecec0f30e7e3b093969e75ca4a1e0b6aa286d
take the first 8 hex characters: 7f7c47d4
read them as a number: 2,138,851,284
scale into a 0 to 100 roll: 49.7990
Change any one of the three inputs, even by a single character, and the whole output changes completely. That is the point. Because your client seed is part of the mix, the site cannot aim a specific result at you, and because the server seed was committed before you played, you cannot aim one either. Different sites use different exact recipes, but the shape is always the same: three inputs, a hash, a number, an item.
Server seed versus client seed
People mix these up, so it is worth being clear. The server seed is the site's input, secret until the reveal. The client seed is your input, visible and changeable. Both exist so that neither party controls the result on its own. If only the site had an input, you would have to trust it. If only you had an input, you could game it. Two independent inputs, one committed in advance, is what makes the outcome something both sides are bound to.
Rotating your client seed also forces the site to reveal the old server seed and commit to a fresh one. That is the moment you can run your check, which is why fairness guides tell you to rotate your seed after a session you want to verify.
How to check a server seed yourself
You do not need to trust any of this on faith. Once a server seed is revealed, you can recompute the whole thing on your own device. The verifier below does exactly that, and nothing you paste into it is sent anywhere.
- Before you play, copy the hashed server seed the site shows you. This is the fingerprint.
- Note your client seed and the play count for the pull you care about.
- After you rotate seeds, copy the revealed server seed.
- Paste all of it into the verifier. It recomputes the outcome and checks that the revealed seed matches the fingerprint you saved.
If both line up, the result was committed before you played and was not altered. If you want the full picture of how the pieces fit together, the what is provably fair guide walks through the entire flow.
Step 1Where did you play?
Using Ripster box / upgrade: HMAC-SHA256 over clientSeed:noncedetails
HMAC-SHA256 keyed with the server seed over clientSeed:nonce. The first 8 hex characters become a 32-bit integer, divided by 2^32 and multiplied by 100 for a roll in [0, 100). Items are sorted by item ID and selected by cumulative probability: the first item whose cumulative probability is at least the roll wins.
Where to find your numbers on Ripster.gg:
- Before rolling, copy the Server Seed Hash from the Provably Fair modal (also recorded per roll in Account History).
- After the roll, open the Provably Fair modal to copy the Server Seed, Client Seed and Nonce.
- Change your Client Seed anytime in Account Settings; doing so reveals the current Server Seed so all past rolls become verifiable.
Source: Ripster.gg's own fairness page
Step 2Paste your numbers
Runs entirely on your device via your browser's built-in cryptography. Don't take our word for it: open DevTools → Network, click the button, and watch: zero requests.
Runs entirely in your browser. Nothing you paste is sent anywhere.
The short version
A server seed is the site's committed secret, shown to you first as a fingerprint and revealed afterward so the result can be proven. Combined with your client seed and a play count, it produces an outcome that neither side can steer and anyone can recompute. Understanding it is most of what you need to check a provably fair pull with confidence.