Tool
Random Decimal Generator
Uniform decimals in a range, with the precision you choose — and the rounding explained.
Random Decimal Generator
Rounding to 2 places collapses the range into 101 possible values. The two endpoints sit at the edge of a half-width bucket, so 0 and 1 each come up about half as often as any value in the middle.
Uniform decimal values anywhere in a range, at whatever precision you need, generated one at a time or fifty at once.
The part worth reading is what rounding does. Asking for two decimal places between 0 and 1 does not give you 101 equally likely values — it gives you 99 equally likely values and two that come up half as often, and almost nothing that produces random decimals mentions this.
The number of possible values after rounding is computed and displayed, because it is the actual size of the outcome space and it is usually much smaller than people picture.
How the Random Decimal Generator works — and why it's fair
The draw is continuous first and rounded second. A 32-bit value from crypto.getRandomValues is scaled to a float in [0, 1), multiplied by the range width, and offset by your minimum — that is a uniform continuous draw across the interval. The rounding to your chosen precision happens afterwards, at display time.
Rounding a continuous distribution into buckets is where the endpoints lose out. Every interior value at two decimal places, say 0.37, captures everything from 0.365 up to 0.375 — a full bucket width of 0.01. But 0.00 captures only 0 up to 0.005, and 1.00 captures only 0.995 up to 1, because there is nothing beyond the interval to round inwards. The two endpoints have half-width buckets and therefore roughly half the probability.
The effect is small in absolute terms and completely real. Over a hundred draws at two places between 0 and 1 you would expect about one 0.00 rather than the two you would get if every value were equally likely. It matters when someone is using the endpoint as a trigger, and it matters more at low precision — at zero decimal places between 0 and 10, the values 0 and 10 each come up half as often as any of 1 through 9.
This is a genuinely different problem from the modulo bias that the integer tools correct with rejection sampling. Modulo bias comes from mapping 256 byte values onto a range that does not divide evenly; endpoint under-representation comes from rounding a continuous quantity into a bounded set of buckets. The first can be eliminated. The second is inherent in rounding, and the honest response is to state it rather than to pretend it away.
If you need every displayed value to be exactly equally likely, generate integers with the random number generator and place the decimal point yourself — an integer draw from 0 to 100 divided by 100 gives 101 genuinely equiprobable values, because the draw was discrete from the start.
When the Random Decimal Generator is fair — and when it is not
What it does guarantee
- The underlying continuous draw is uniform across the whole interval, with no clustering anywhere.
- Every interior rounded value has exactly the same probability as every other interior value.
- The number of distinct possible outputs after rounding is computed from your settings and displayed.
What it does not
- The two endpoints come up about half as often as interior values, because rounding gives them half-width buckets.
- At low precision the outcome space is much smaller than the range suggests — 0 to 10 at zero places is eleven values, not a continuum.
- Successive draws are independent, so a batch of fifty can easily contain near-duplicates.
Two worked examples
0 to 1, two decimal places
- 101 possible outputs, from 0.00 to 1.00.
- Each of the 99 interior values has probability 0.01; 0.00 and 1.00 each have about 0.005.
- Over 1,000 draws expect roughly 10 of each interior value and about 5 of each endpoint.
0 to 10, zero decimal places
- Only 11 possible outputs, which surprises people who set a wide range and no precision.
- The values 1 through 9 each have probability 0.1; 0 and 10 each have about 0.05.
- For eleven genuinely equal outcomes, use the integer generator with a range of 0 to 10 instead.
Where a decimal is the right output
Simulation and modelling inputs are the main use: a random coefficient, a random starting position, a random weight in a range. In those settings the continuous draw is what you want and the rounding is only display, so the endpoint caveat rarely bites.
Teaching probability is another, and here the caveat is the lesson. Generating a few hundred values at one decimal place and tallying them produces a visible endpoint deficit, which is a far better demonstration of what rounding does to a distribution than any explanation.
Randomised measurement and testing use it where a value needs to fall anywhere in a tolerance band rather than at a round number — a random tare weight, a random delay in seconds, a random price point within a band being tested.
For whole numbers, the random number generator uses rejection sampling and has no endpoint problem at all. For splitting a total into random parts that must sum exactly, the percentage allocator is the correct tool, because independent decimal draws will not sum to anything in particular.
Frequently asked questions
Why are the endpoints less likely?
Because rounding gives them half-width buckets. An interior value captures a full bucket either side of itself; an endpoint has nothing beyond the interval to round inwards from.
How big is that effect?
The endpoints come up about half as often as interior values. Over a thousand draws at two places, roughly 5 endpoint hits against 10 for each interior value.
Is this the same as modulo bias?
No. Modulo bias comes from mapping bytes onto a range that does not divide evenly, and rejection sampling eliminates it. Endpoint deficit is inherent in rounding a continuous quantity.
How do I get genuinely equal decimal values?
Draw integers instead and place the decimal point yourself. An integer draw from 0 to 100 divided by 100 gives 101 exactly equiprobable values.
Can I generate negative decimals?
Yes — set a negative minimum. The range is whatever you specify and can straddle zero.
Why cap the batch at fifty?
Because beyond that the output stops being readable on screen. For bulk generation you want a script, not a page.
Are the values in a batch independent?
Yes, entirely. A batch can contain two values that round to the same number, and often will at low precision.
What if my minimum is above my maximum?
The range is used as given; a zero or negative width simply returns the minimum. Swap the fields to get the range you intended.
How many decimal places can I ask for?
Up to ten. Beyond that you exceed the precision a 32-bit draw scaled to a float can meaningfully supply, and the extra digits carry no information.