Math.random() returns a number between 0 and 1, and roughly nobody reading this could explain what happens between the call and the return. That is fine, fine right up until the output decides who gets money, and then it becomes one of the genuinely hard problems in applied software, the kind that regulated industries build entire testing labs around.
Start with the thing most people get wrong: a sequence that passes for random and a fair sequence are different claims, and your users cannot tell them apart by staring at outputs. The users will never catch the difference and that is the whole problem in one sentence. This is why fairness in any real-money system, an online casino being the sharpest example, is a verification problem long before it is a math problem.

Pseudorandom generators are deterministic. A PRNG eats a seed, runs it through fixed arithmetic, and spits out numbers that sail through statistical randomness tests while being completely predetermined by that seed. Mersenne Twister is the poster child: excellent distribution, used everywhere by default for years, and from a few hundred observed outputs you can reconstruct its internal state and predict the rest. For a Monte Carlo simulation, who cares! For anything where a human has a financial reason to guess your next number, you just shipped a vulnerability and called it a feature.

What you want when stakes exist is a CSPRNG. The guarantee that matters: even with a long history of outputs, an attacker cannot compute the next one or recover the internal state. crypto.randomBytes() in Node. crypto.getRandomValues() in the browser. They sit one autocomplete away from the unsafe option and offer wildly different guarantees, which is exactly why this bug ships so often. The safe call and the dangerous call look like fraternal twins.

**

The part players actually rely on

**
Say you build it correctly: a proper CSPRNG, real entropy, no timestamp nonsense.
You know it is fair but now prove it to a stranger who assumes you are lying…
That is the real problem, and it is harder than the cryptography. In a regulated market like Ireland, an online casino does not get to grade its own homework, and that constraint is the whole point. A licensed and trustworthy casino online in Ireland has to hand its generator to independent testing labs that run NIST, Diehard, and TestU01 batteries against millions of trials, usually with visibility into the seeding process, hunting the failures that never surface casually: bias in the low-order bits, short periods, correlation between consecutive draws, seeds derived from something guessable.

Irish players never see any of that complex machinery. They only get a third-party certification standing in for trust they have no other way to establish, because the output stream alone proves nothing. A rigged system can emit statistically flawless results across millions of spins while quietly tilting the few outcomes where the money moves.
So the certification is not bureaucratic theatre, the only thing standing between "looks random" and "is verifiably fair," and it exists precisely because no user can audit a server they cannot see.

Where it gets clever

We are going to highlight the part worth your attention as an engineer, because you can steal and apply it to what you do.
There is a class of schemes that lets a user verify one specific result without trusting the operator at all. The usual construction is a commitment scheme where the server generates a secret seed and publishes its hash before anything happens, the client throws in its own value, and the outcome is computed from both together. Once the round is done, the server reveals the original seed, and anyone can hash it, check it against the commitment posted earlier, and recompute the result by hand.

Sit with why that closes both attacks. The server cannot swap its seed after seeing the client's contribution, because the revealed seed would no longer hash to the published commitment and the fraud becomes visible to everyone at once. The client cannot steer the result either, because it commits blind and never sees the server seed until the round is over. Neither party trusts the other and neither has to.

If that smells like blockchain verification, it is the same primitive, which is why provable-fairness systems lifted the toolkit wholesale.
The reason most online casinos still lean on lab certification rather than pure provable-fairness cryptography is latency and product friction, not ignorance. Commitment-reveal adds round trips and complexity that a live, high-throughput gaming floor does not always absorb cleanly, so the licensed operators tend to run certified CSPRNGs under independent audit and treat cryptographic verifiability as a supplement rather than the whole story.

The rule, stripped of the casino

*Choosing a secure generator is the easy half. *
The hard half is architecting the system so its correctness can be verified from the outside by someone who distrusts you, instead of asserted from the inside by the person who wrote it.
An online casino in a regulated market has that constraint forced on it by law, which is why it is such a clean example. Most of your systems will never face an auditor. The ones that handle money, fairness, or anything a user has incentive to game will, and Math.random() was never going to get you there.