A single draw chooses one roster position
Every non-empty name is one eligible position. Four distinct names give each position probability 1/4 on one draw. The tool chooses an index uniformly from that list; it does not assign hidden weights based on spelling, order, past results, or browser identity. Empty lines are ignored so visual spacing does not create invisible tickets.
Names that identify the same person must be resolved before drawing. Two entries called Jordan are two tickets unless you label them Jordan K. and Jordan M. A duplicate may be intentional, but then the rule is weighted: that text has two of the available positions.
What the local history records
After a successful draw, the page stores a short text record in this browser's local storage: the device's local date and time, the selected name, and the number of eligible entries. It retains the newest 20 records and displays the newest three. This helps a club or classroom see what this browser previously drew without creating an account or sending the roster to DiceDecide.
Local storage belongs to the browser profile, not to the event. Clearing site data, using private browsing, changing browsers, or opening another device can remove or hide that history. It is a convenience log, not a tamper-proof register, shared database, or proof of attendance.
Worked example with four volunteers
Enter Avery, Blake, Casey, and Dev. If the random index is 2 when counting from zero, the selected name is Casey. The record might read “8/14/2026, 10:32 AM: Casey (4 eligible).” Each of Avery, Blake, Casey, and Dev had the same 25% chance before the click.
Pressing Run tool again creates a fresh independent draw from the full current list. Casey remains eligible unless you edit the list. This is correct for repeatedly choosing a discussion starter, but wrong for selecting several different prize winners. For distinct winners, remove a winner from the list before the next draw or use a no-repeat selector.
A defensible procedure for an informal draw
Read the roster and the redraw rule aloud before running it. For example: “These eight present volunteers are eligible; one name is drawn; a redraw occurs only if the person is absent.” Then paste the roster, run one draw, and copy the result or take a screenshot. The local history can support that record, but it should not be the only copy if the outcome matters.
Do not add a late name after seeing a winner and call the second draw equivalent to the first. The population changed from N entries to N+1, so each probability changed. If a correction is necessary, state whether the original draw is void or whether the new person is handled by a separate rule.
Where it is useful and where it is not
This fits low-stakes turns, icebreakers, casual giveaways, task volunteers, and choosing who starts a board game. It is not suitable for regulated promotions, elections, hiring, school discipline, access rights, or any situation that needs independent verification and a durable audit record. Fair random selection cannot repair an unfair eligibility list.
A published process needs more than a name on a screen: eligibility, time zone, deadline, consent, duplicate handling, redraw conditions, and retention requirements may all matter. Those policies are outside a browser tool.
Input failures that change fairness
A pasted roster can contain a trailing space, a blank line, or two spellings for one person. Blank lines are safely ignored; duplicate names are rejected rather than silently becoming extra tickets. Distinguish coincidentally identical names with an agreed label. If you intend unequal chances, use a weighted draw that shows the weights instead of disguising them as duplicates.
The history is intentionally capped at 20 entries so it does not become an uncontrolled personal archive. It contains only what this page writes after a draw, but a shared computer is still the wrong place for a sensitive participant list.
How this draw differs from related tasks
This page selects exactly one roster entry and adds a local history record. A shuffle produces a complete order; a duty scheduler assigns many dates; a constrained selector prevents the immediately previous result; and a unique-number generator works from an integer interval rather than names. The difference is the probability object, not the button label.
The output remains in the page and in the browser storage described above. It is not posted to a service endpoint, emailed, or made visible to other visitors.