Learning how to verify provably fair is simpler than it sounds: you are checking two things about a pull you already made. First, that the site used the exact secret it committed to before you played. Second, that your outcome really came from that secret combined with your own inputs. If both hold, the result was locked in before you opened the box and nothing was changed afterward. You do not need to trust anyone's word for it, because you can recompute the whole thing yourself, and the check below walks through every step.
What verifying provably fair actually checks
A provably fair check is two smaller checks stacked together, and it helps to name them before you start.
The first is the commitment check. Before your pull, the site showed you a hashed server seed: a one-way fingerprint of a secret it had already chosen. After you finish, it reveals the real secret. You hash that revealed secret yourself and confirm it produces the exact fingerprint you were shown up front. If it does, the site could not have swapped in a different secret partway through, because a different secret would produce a different fingerprint.
The second is the outcome check. You take the revealed server seed, your client seed, and the play count, and you run them through the same math the site uses to turn those three inputs into a result. If the number you get matches the item or roll you actually received, the outcome was fixed by inputs that existed before you played.
Pass both and the result is proven: committed in advance, and not altered. That is all "provably fair" claims, and it is exactly what you are confirming.
What you need before you start
Gather four values. Three of them you can note during normal play, and the fourth appears only after you rotate your seed.
- The hashed server seed. The fingerprint the site shows before your pull. Copy it before you play, because this is the commitment you are going to test against. If you want the full picture of what this value is, the server seed guide covers it.
- Your client seed. The value tied to your account. It is visible and you can usually set it yourself.
- The play count, or nonce. A counter that ticks up by one each pull, so every result in a sequence is different. If the counter is new to you, the nonce guide explains why it matters.
- The revealed server seed. The real secret behind the fingerprint. You only get this after you rotate to a new server seed, which is the step most people miss.
You do not have to grab these before you play to check later, but saving the hashed server seed up front makes the commitment check airtight.
How to verify provably fair, step by step
Here is the full sequence. The exact labels differ between sites, but the shape never changes, because every provably fair system uses the same commit-then-reveal structure. For the whole idea behind that structure, the provably fair overview walks through it end to end.
- Save the commitment. Before your pull, open the fairness or seeds panel and copy the hashed server seed. This is the value the site is locked into.
- Note your inputs. Record your client seed and the play count for the pull you want to check. Both are usually in the same panel.
- Rotate your seed. Switch to a new server seed. This forces the site to reveal the old one, since it no longer needs to keep it hidden. Nothing reveals until you do this.
- Copy the revealed server seed. Grab the real secret the site now shows for the seed you just retired.
- Recompute and compare. Hash the revealed server seed and confirm it matches the fingerprint from step one. Then run the server seed, client seed, and play count through the site's formula and confirm the result matches what you received.
The last step is the one that sounds like work, and it is where a verifier does the heavy lifting for you. Paste your four values in, and it runs both checks at once: the fingerprint match and the outcome. Everything happens on your own device.
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.
Doing it by hand versus using a verifier
You can verify entirely by hand. Hash the revealed server seed with a plain SHA-256 tool, compare it to the fingerprint, then work the site's formula to reach the outcome. It is tedious but real, and doing it once is a good way to convince yourself nothing is hidden.
For anything past a single check, a verifier is faster and less error-prone, with one condition: it must run in your browser, not on a server. When a tool computes on your own device, the values you paste never leave it, so you are not handing your seeds to anyone. A tool that sends them to a remote server asks you to trust that server, which defeats the reason you are verifying at all. You can confirm this for yourself by opening your browser's developer tools and watching for network requests when you click verify: a client-side tool fires none.
The exact formula, seed order, and slice differ from site to site, so a general check gets you the concept while the per-platform pages carry the precise recipe each operator publishes. If you want to test a whole run at once instead of one pull, the batch verifier checks a range of play counts in a single pass.
When the check does not match
A mismatch does not always mean something is wrong. The most common cause is a small input error: a client seed copied with a trailing space, the wrong play count, or a server seed grabbed before it was actually revealed. Recheck each value first.
If the fingerprint does not match the revealed seed after careful entry, that is the meaningful failure, because it means the revealed secret is not the one that was committed. If the outcome does not match but the fingerprint does, confirm you are using the site's exact formula, since seed order and separators vary. And remember what this process is for: it verifies a result that already happened. It cannot predict a future pull, and any tool that claims to is a scam, because the server seed is committed before your client seed even exists.
The short version
To verify provably fair, save the hashed server seed before you play, note your client seed and play count, rotate your seed so the real server seed is revealed, then recompute: confirm the revealed seed matches the fingerprint, and confirm the outcome matches your result. A browser-based verifier does both at once without ever sending your seeds anywhere, which is what makes the answer something you can trust rather than take on faith.