Why JemLit is the easiest site to check
Most operators describe their algorithm in prose and leave you to guess the details. JemLit publishes an actual worked example: a set of seeds and the exact roll they produce. That sounds minor. It is the difference between an algorithm you can implement and one you can only approximate.
We used that example to confirm our implementation reproduces roll 22.0231 from JemLit's own published inputs. When the verifier above returns a match on your own pull, it is running the same code path that already agrees with JemLit's documentation.
The formula, precisely
key = serverSeed
message = clientSeed-nonce (hyphen separator)
|
v
HMAC-SHA512/256
|
v
full 64-character digest as one integer
|
v
( integer / 16^64 ) x 100 = roll between 0 and 100
Three of those details trip people up, and in each case the widely repeated version is wrong.
| Detail | Commonly reported | What JemLit actually uses |
|---|---|---|
| Hash function | SHA-256 | HMAC-SHA512/256 |
| Separator | clientSeed:nonce | clientSeed-nonce, a hyphen |
| Digest used | First 8 or 13 hex characters | All 64 |
| Nonce starts at | 0 | 1 |
| Commitment hash | SHA-256 | SHA-512 |
The hash is HMAC-SHA512/256
This is not SHA-256, and it is not ordinary SHA-512. It is SHA-512 truncated to 256 bits, a distinct function with its own initial values, so it produces different output from both. Several review sites state JemLit uses SHA-256. They are wrong, and a verifier built on that description will never match a real JemLit roll.
The separator is a hyphen
The message is clientSeed-nonce, not clientSeed:nonce. Colon-separated formats are common elsewhere, and swapping one for the other changes the digest completely.
Nothing is sliced off
Many sites take the first 8 or 13 hex characters of the digest. JemLit converts all 64 of them into a single integer, divides by 16 to the power of 64, and multiplies by 100. That yields a roll anywhere from 0 to 100, reported to four decimal places.
The nonce starts at 1, not 0. If your first recorded pull will not reproduce, an off-by-one nonce is the first thing to check.
From roll to item
The roll on its own is a number like 22.0231. Every item in a box publishes a win range, and the item whose range contains your roll is what you pulled. The boundary rule is that a roll wins an item when it is greater than the range's lower bound and less than or equal to the upper bound, which matters only in the rare case where a roll lands exactly on a boundary.
This is what makes the check worth running. Reproducing the roll proves the number was fixed before you opened. Seeing which published range it falls into proves that number maps to the item JemLit actually handed you.
The commitment uses SHA-512
Before you open anything, JemLit shows a fingerprint of the server seed. That fingerprint is a SHA-512 hash, not the SHA-256 that most platforms use for the same job.
It is an easy detail to miss and it produces a confusing failure. If you check the commitment with SHA-256 it will never match, no matter how correct everything else is, and the natural conclusion is that the site did something wrong. It did not. You used the wrong hash function.
Where to find your seeds
JemLit keeps all three values in one place: the Fairness popup at the top of the page. On mobile it sits in the top-left menu instead. The popup shows your current client seed, which you can edit, the hashed server seed for the seed in use, and your play count.
To get a revealed server seed you have to rotate: set a new client seed, which retires the old server seed and publishes it in full. Everything you opened under that seed is then checkable, including with the tool above.
What this page confirms, and what it does not
JemLit's unboxing mode is the one we have confirmed. Our implementation reproduces its published worked example exactly, which is why the verifier above accepts JemLit pulls rather than showing an "awaiting confirmation" notice.
A passing result means one specific thing: the pull you are checking came from values committed before you opened, and JemLit did not alter it afterwards. It does not speak to whether an item's stated chance is generous, whether a withdrawal will arrive, or how support behaves when something goes wrong. Those are real questions and a fairness check is simply the wrong instrument for them, which is why we keep what verification cannot prove as a standing page.
If a roll you know is real will not reproduce here, the order to check is: nonce starting at 1, the hyphen separator, and HMAC-SHA512/256 rather than SHA-256. In our experience those three account for nearly every mismatch on this platform.