Entropy Visualizer
True randomness from the void
Why this is more random than Math.random()
The plain-language version
When a program calls something like Math.random(), it's not actually rolling dice. It's reading from a pre-baked script of numbers produced by a math formula, starting from a predictable seed (usually something like "the current millisecond"). If someone figures out the recipe and where you started reading, they can predict every number you'll ever get — past, present, and future.
That sounds abstract until you remember what it has actually been used to do: drain online poker sites, empty crypto wallets whose private keys were generated from weak randomness, and hijack "unguessable" password reset links. For anything where unpredictability matters — passwords, keys, secrets, fair drawings — Math.random() is not safe.
This tool gets its randomness from somewhere fundamentally different: the physical, chaotic state of your device and your own movements. Nobody can predict it. Nobody can replay it. Not even you.
That's the core idea. This tool's "kitchen" is your computer and your hand. Every mouse movement, every microsecond of timing, every thermal fluctuation in the CPU, every hardware interrupt — all of it gets fed into the randomness. Your numbers come from a process that literally cannot be simulated or replayed.
The technical version
Every number this page generates is produced by a two-source mixing pipeline. Both sources have to be broken independently for the output to become predictable — a property cryptographers call defense in depth.
Your operating system continuously collects entropy from hardware noise — CPU timing jitter, interrupt timing, disk and network event timing, and on modern chips a dedicated hardware RNG like Intel RDRAND or ARM TRNG. Browsers expose this through crypto.getRandomValues(), a Cryptographically Secure PRNG (CSPRNG). This is the gold-standard randomness used by banks, certificate authorities, and crypto wallets.
As you move your cursor or finger across the canvas, every event feeds the X/Y coordinates and a microsecond-precision timestamp into a 256-byte pool via XOR mixing. The exact trajectory of your motion is unpredictable to anyone who isn't watching you in real time — even you can't reproduce it.
On every mouse event, the tool asynchronously runs crypto.subtle.digest('SHA-256', pool + timestamp + previous key) and stores the 32-byte result as a mixing key. SHA-256 is a one-way cryptographic hash: even if an attacker saw the output, they cannot reverse-engineer the inputs. The key is constantly stirred by your motion.
When you click a generator button, the tool calls secureFill(buffer). It pulls base randomness from crypto.getRandomValues(), then XORs every byte with the current mixing key. XOR with a uniformly random key is provably as strong as either source alone — if the OS CSPRNG were somehow weakened, your mouse entropy still protects you; if your mouse entropy were low (a fresh page load, no motion yet), the CSPRNG still protects you.
Immediately after generation, the mixing key is rotated by XOR-ing it with a fresh OS sample. This means observing one output gives an attacker no information about the next — the key has already moved on. This is the property cryptographers call forward secrecy.
Side-by-side comparison
Each column adds a layer of protection over the previous one. All four of the non-Math.random() options are cryptographically secure in practice — the later columns are defense in depth for paranoid and high-stakes use cases.
Math.random()JavaScript PRNG |
crypto.Browser CSPRNG (OS entropy) |
CSPRNG + 1 entropy sourceThis tool — mouse / touch | CSPRNG + 3 entropy sourcesEntropic Tarot — mouse + mic noise + cam noise | |
|---|---|---|---|---|
| Core source | Math formula + predictable seed | OS entropy pool (hardware noise, interrupt jitter, RDRAND) | OS CSPRNG XOR SHA-256 of mouse/touch pool | OS CSPRNG XOR SHA-256 of mouse + microphone dark noise + camera dark noise |
| Deterministic? | Yes — identical output if seed is known | No — OS pool re-seeds from hardware continuously | No — both layers must be predicted | No — all four layers must be predicted |
| Replayable? | Yes — same seed = same sequence | No | No — mouse trajectory never repeats | No — physical environment never repeats |
| Predictable from observation of prior output? | Yes — a few samples reveal the seed | No — pool is one-way hashed forward | No — key rotates after every call | No — multiple independent pools rotate |
| Number of independent sources of entropy | 0 (it's a recipe) | 1 (OS pool — many sub-sources but one interface) | 2 (OS pool + user motion) | 4 (OS pool + motion + mic noise + cam noise) |
| Survives a catastrophic CSPRNG flaw? | N/A — no CSPRNG | No — single point of failure | Partially — user motion still adds unpredictability | Yes — three physical sources remain |
| Survives a catastrophic hardware RNG flaw (e.g. RDRAND backdoor)? | N/A | Depends — OS pool mixes other sources, usually OK | Yes | Yes (strongest) |
| Forward secrecy (observing now leaks nothing about the past)? | No | Yes | Yes | Yes |
| Backward secrecy (compromising state now reveals nothing about future)? | No | Yes — OS reseeds | Yes — key rotates + reseeds | Yes (strongest) |
| Requires user permission? | No | No | No (passive mouse events) | Yes — mic and camera need explicit allow |
| Works headless / no user motion? | Yes | Yes | Degrades — falls back to CSPRNG alone | Degrades — falls back to CSPRNG alone |
| Statistical quality (Chi-square, NIST SP 800-22) | Passes basic tests, fails cryptographic tests | Passes all standard randomness tests | Passes all standard randomness tests | Passes all standard randomness tests |
| Good enough for games & UI animations | Yes | Yes (overkill) | Yes (overkill) | Yes (absurd overkill) |
| Good enough for passwords / session tokens | No | Yes | Yes | Yes |
| Good enough for cryptographic keys | No | Yes | Yes | Yes |
| Good enough for high-stakes fair drawings (lottery, gambling, auditable randomness) | No | Yes, but not auditable | Yes | Yes, with visual audit trail |
| Good enough for nation-state adversaries | No | Usually — depends on OS & hardware trust | Yes — defense in depth | Yes — highest assurance |
| Typical callers / examples | Games, UI animations, JS tutorials | Most web apps, banks, SSL/TLS, cloud SDKs | This tool, privacy-focused password managers | Entropic Tarot, high-assurance key generation, HSMs |
Verify it yourself
Every piece of this is in the page's source. No external calls, no server roundtrip, no hidden dependencies. Open DevTools, find secureFill, and watch the two-source mixing happen on every click. The Chi-Square Uniformity readout above samples the generated bits and measures whether they look uniformly distributed across all 256 byte values — a basic but meaningful statistical test that a broken generator would fail.
The honest fine print: crypto.getRandomValues() alone is already cryptographically secure for every realistic purpose. The mouse-entropy mixing layer is defense in depth, not a replacement. If the browser's CSPRNG were catastrophically compromised (never documented in any mainstream browser), your mouse movements would still add unpredictability an attacker cannot see. It's belt-and-suspenders engineering, not a workaround for a known flaw.