Random bytes, from a generator you can trust
Tokens, keys, nonces and identifiers from crypto.getRandomValues — your browser's cryptographically secure generator, seeded by the operating system. Integer ranges use rejection sampling, so no value is quietly more likely than another.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
Why a range needs more care than it looks
The obvious way to get a number from 1 to 100 is to take a random 32-bit value and use the remainder after dividing by 100. It is also wrong: 2³² is not a multiple of 100, so the first 96 residues come up very slightly more often than the last four. The bias is tiny — about one part in forty million — and it is real, it is systematic, and it costs nothing to remove.
The fix is rejection sampling. Work out the largest multiple of the range that fits in 32 bits, throw away any draw at or above it, and take the remainder of what is left. Every value in the range then has exactly the same number of 32-bit patterns mapping to it. That is what this page does, and the shared engine's test suite draws sixty thousand values and checks the buckets land within three per cent of even.
How many bits do you need?
128 bits for anything that has to be unguessable — session tokens, API keys, password reset links, invite codes. There is no attack against 128 bits of real randomness and there is not going to be one.
256 bits where the value is a cryptographic key, or where you would rather not think about it again. It is the default here for that reason.
Below 64 bits, start thinking about how many values will exist and who can guess at them. A 32-bit token in a system with a million active ones is not a security control.
Going far past 256 buys nothing at all. A 4,096-bit token is not more unguessable than a 256-bit one; it is just longer, and it will end up truncated by something.
A UUID is not a secret
A version 4 UUID contains 122 random bits, which is plenty to be unguessable — but UUIDs are designed to be unique, not secret, and everything around them assumes that. They get logged, put in URLs, included in error reports, and handed to third parties, because that is what identifiers are for.
If a value needs to be unguessable, generate a token and treat it like a password. If it needs to be unique, a UUID is the right tool and there is no reason to invent something else.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
Which format to pick
Hex is unambiguous and easy to compare by eye, at the cost of two characters per byte. It is what most cryptographic tooling prints.
Base64url is the compact choice for anything going in a URL, a cookie, or a JSON field — it uses - and _ in place of + and /, so nothing needs escaping. Plain Base64 is the same encoding without that adjustment.
Base32 is longer again but avoids every pair of characters people confuse, which is why it is used for values that get read aloud or typed from a screen — TOTP secrets, recovery codes, licence keys.
What this cannot tell you
Whether the output is "random enough". Every value here comes from the same generator the browser uses for TLS key material, and inspecting a particular output tells you nothing about the process that produced it — a fair coin can land heads ten times. Statistical tests on a few hundred bytes from a CSPRNG are theatre; the assurance comes from the generator, not from the sample.
Related
The password generator for something a person will handle, or the encoding converter to move a value between representations.
Questions people actually ask
What generates these?
crypto.getRandomValues — the browser's cryptographically secure random number generator, seeded by the operating system. It is the same source the browser uses for TLS key material. Math.random is never used, and the test suite reads the source files to make sure.
Why does a number range need special handling?
Because the obvious method is biased. Taking a 32-bit value modulo 100 makes the first 96 residues very slightly more likely than the last four, since 2³² is not a multiple of 100. Rejection sampling — discarding the draws that fall in the incomplete final block — removes it entirely, and the engine's tests draw sixty thousand values to confirm the buckets land within three per cent of even.
How many bits should a token be?
128 for anything that must be unguessable, and 256 if it is a key or you would rather not think about it again. Below 64, consider how many such values will exist and who can guess at them. Beyond 256 you gain nothing — a longer token is not a less guessable one, and something downstream will truncate it.
Can I use a UUID as a secret?
You should not. A version 4 UUID has 122 random bits, which is plenty of entropy, but everything around UUIDs assumes they are identifiers rather than secrets — they get logged, put in URLs, and passed to third parties. If a value needs to be unguessable, generate a token and treat it like a password.
Can I check the output is really random?
Not from a sample, and neither can anyone else. A fair coin can land heads ten times in a row; statistical tests on a few hundred bytes tell you about the sample, not the process. The assurance comes from the generator being the platform's CSPRNG, which is auditable in a way that any particular output is not.
Is anything sent anywhere?
No. Values are generated in your browser and stay there. The download button writes a file locally with no upload step.