When a custom list is the right model
A custom list is useful when eligibility cannot be described by every integer in one continuous range. Inventory codes 4, 19, 42, and 105 have gaps; −2.5, 0, and 8.75 include decimals; a saved set of record identifiers may arrive in no numerical order. The Random Number Picker selects only from values entered, whereas the Random Number Generator can return any integer between its minimum and maximum.
Input: 4, 19, 42, 105. Request: one number. Eligible pool: four unique values. Result: one of those four values, never an integer in a gap. Interpretation: each value has first-pick probability 1/4 when the random index mapping is uniform. Save the exact source list before drawing so the population can be reviewed later.
Accepted separators and numeric values
Separate entries with commas, spaces, semicolons, tabs, or line breaks. The parser applies JavaScript Number conversion to each nonempty token and keeps finite results. Negative numbers, zero, decimals, and scientific notation such as 1e3 are therefore accepted. Numeric spellings that convert to the same number, such as 1, 1.0, and 01, become one value after deduplication.
This permissive conversion has consequences. Tokens that are not finite numbers—such as apple, NaN, and Infinity—are silently discarded rather than producing a token-specific error. A mixed input can still draw from the remaining valid values. Review the displayed Unique eligible numbers count before selecting. If the count is lower than expected, correct the source list instead of accepting an incomplete pool.
Duplicate values become one eligible value
The picker constructs a set of numeric values, so duplicates do not add chances. Input: 5, 5, 8, 13, 13. Process: numeric conversion followed by duplicate removal. Calculation: five tokens become three unique values. Result: eligible pool {5, 8, 13}. Interpretation: each distinct number has first-pick probability 1/3, not 5 a probability of 2/5 and 13 a probability of 2/5.
This behavior is correct for a set of unique identifiers with accidental repeated lines. It is wrong for a design where repeated entries intentionally represent weights. The picker cannot preserve duplicate-value weights, nor can it detect that different numeric identifiers belong to the same person. Define the selection unit first and use a purpose-built weighted method if unequal chances are required.
Picking several values without replacement
Input: −4, 0, 2.5, 11, 40. Request: three numbers. Process: choose a random index from the five-value pool, remove that value, choose from four, then choose from three. Result: three distinct values drawn only from the list. Interpretation: order records the sequence of picks, while the final unordered set contains the same three selected values regardless of display order.
The current picker uses Web Crypto when available and rejection sampling to map a 32-bit value evenly to the current pool size. If Web Crypto is unavailable, its helper falls back to Math.random(), which is not cryptographically secure. The tool does not certify the list or produce an audit trail, so use it for informal selection rather than regulated drawings or scientific samples requiring a controlled protocol.
Count limits and empty-list behavior
The requested count is converted to a number, rounded down, and then required to be an integer from 1 through the number of unique eligible values. Because the rounded result is tested for integer status rather than the original input, a value such as 2.9 currently behaves as 2. Use an explicit whole number to avoid ambiguity. A blank, zero, negative, nonnumeric, or excessive count returns a message instead of a selection.
Input: 2, 2, 7, 9 with requested count 4. Calculation: the list contains only three unique values. Result: the tool asks for a count between 1 and 3. Interpretation: sample size cannot exceed the unique pool when sampling without replacement. An empty list or a list containing only invalid tokens reports that at least one valid number is required.
A repeatable list-preparation workflow
Export or write the eligible numbers, confirm that every identifier maps to one intended unit, decide whether duplicate numeric values are errors, and preserve the original file. Normalize separators only after retaining that evidence. Paste the list, compare the displayed unique count with your reviewed count, enter the required sample size, and make one selection under the pre-agreed rules.
Record the source-list version, count, requested size, time, and displayed result when traceability matters. Avoid editing the list after seeing an outcome, rerunning because the values look clustered, or treating output order as an extra ranking unless ranking was part of the rule. For a full fairness procedure, use the fair-selection guide; for the conditional probability behind removal, use the sampling-without-replacement guide.
What the picker does not validate
The picker accepts numbers, not labels or mixed identifiers. It cannot know whether 0012 and 12 were meant to be different textual codes because both become numeric 12. It cannot preserve leading zeros, attach names, check eligibility dates, reconcile source files, or detect identity duplicates. If those distinctions matter, assign verified unique numeric identifiers outside the tool and keep the mapping securely.
Do not paste confidential personal data into a numeric selector. Do not describe an everyday browser result as regulated, notarized, audited, or scientifically certified. The tool's core behavior is narrow: parse finite numeric values, remove numeric duplicates, choose one or more indices, and remove each chosen value from the working pool. Its usefulness depends on a correct list and an appropriate procedure.
Very large or highly precise decimal identifiers are also risky because JavaScript numbers have finite binary precision. Two different textual integers beyond the safe-integer limit can normalize to the same numeric value. Use compact safe numeric IDs and verify the unique count rather than treating the picker as a lossless database-key parser.
Four checks before accepting a custom-list result
First compare the displayed unique count with an independently reviewed count. Input: 10; 10.0; −3; 0; 2.5. Calculation: 10 and 10.0 normalize to the same number, leaving four unique values. Result: the interface should show 4. Interpretation: numeric identity, not textual spelling, controls eligibility. If five textual codes were intended, this tool is unsuitable until unique numeric IDs are assigned.
Second, test the requested sample boundary. With those four values, count 1 returns one value and count 4 returns all four in a random order without repeats. Count 5 must be rejected. Third, scan the raw source for tokens such as 12kg or ID-7; the parser discards them rather than explaining which rows failed. A successful draw from the surviving numbers does not validate the discarded records.
Fourth, preserve the list and decide whether order matters. The picker reports a selection sequence because values are drawn one after another. If the task needs only an unordered sample, do not invent first-place and second-place meaning afterward. If it needs ranked alternates, announce that the displayed order determines rank before drawing. These checks connect the interface behavior to the selection rule and prevent a technically valid result from answering the wrong question.
Finally, remember that editing the text area resets the displayed result. That prevents an old result from appearing beside a new list, but it does not save either version. Capture the reviewed input separately when traceability matters, and never rely on browser history as the authoritative list.