Research Participant Allocation Generator

What this generator does

Guarantees balance rather than expecting it. The team generator here splits a list once; a shuffle gives balance on average and not on any particular run. This deals from a fixed multiset — every block contains exactly the same number of each group — so the balance is a property of what is dealt rather than of the draw, and no run of bad luck can break it. Where the last block is short, the resulting imbalance is reported rather than hidden.

How to use this tool

1. Paste your participant ids, one per line — codes rather than names.
2. List the groups you are allocating to, one per line.
3. Set a block size that divides evenly by the number of groups.
4. Add strata if you need balance within sites, then randomise and copy the CSV.

Understanding the controls

Participants

One id per line. Use codes rather than names — not because anything is uploaded (nothing is), but because an allocation list is a document that gets shared, and a list of codes is the one you can share.

Arms

One per line, two or more. These are the groups being allocated to, and the block size has to divide evenly by how many there are.

Block size

How many allocations are balanced together. Four with two arms means every four consecutive participants are two and two. Smaller blocks give tighter balance and are easier to guess; larger blocks are less predictable and allow more temporary drift.

Strata

Optional. Each stratum runs its own independent block sequence, which is what keeps the arms level inside every site rather than only across the whole sample.

Seed

Reproduces the same list. Leave it blank for a fresh draw from the browser's secure generator, which is the right default for a real allocation.

Worked examples

40 participants, 2 arms, block of 4

Exactly 20 and 20, on every run — not on average.

33 participants, 2 arms, block of 4

Eight complete blocks, then one of one. The page names the resulting difference.

24 participants across 3 sites

Each site balanced in its own right, not just the total.

3 arms with a block of 6

Two of each arm in every complete block.

Common use cases

• Assigning participants to conditions in a study or pilot
• Splitting a class or cohort into comparison groups that stay level as people join
• Allocating users to variants where you need balance rather than a raw coin flip
• Randomising within sites so no site is over-represented in one arm
• Producing a numbered allocation list somebody else can hold

How this generator works

Participants are divided into blocks in the order you listed them, separately within each stratum. Each block is filled from a bag containing exactly the same number of copies of every arm, shuffled — so a complete block cannot come out unbalanced no matter what the shuffle does. The finished list is then checked: every complete block must contain exactly the expected count of each arm, every participant must appear once, and the arm totals must add up to the number of participants. Where the final block is short, the page states the resulting difference and what would close it.

Randomness and fairness

The draw shuffles each block's bag of arm labels. That is the only randomness — the block boundaries, the stratification and the balance guarantee are all structural. Without a seed the shuffle uses the browser's cryptographically secure generator; with a seed it uses a documented non-cryptographic one, which makes the list reproducible and therefore predictable to anybody who has the seed.

For how randomness is produced across the whole site, see how Generate Random works.

Assumptions this tool makes

• The order you list participants in is the order they will be allocated in.
• Every participant is eligible for every arm.

Limitations and good to know

• It produces the sequence. It is not a trial management system, and it does not track who was actually recruited or what happened to them.
• The list is generated and displayed in your browser, so it is visible to whoever generates it — that is not concealed allocation.
• It does not calculate sample size, power or anything about the analysis.
• Minimisation and adaptive designs are not implemented; this is permuted-block randomisation only.
• The allocation list exists only until the page is closed. Export the CSV — an allocation you cannot produce again is not auditable.

Common mistakes

Using a block size equal to the number of arms

A block of two with two arms means every second allocation is completely predictable from the first. Use a larger block, or vary it, where anybody involved could benefit from guessing.

Generating the list in front of the person recruiting

Concealment is a procedure, not a feature. If it matters, somebody independent should generate and hold the list.

Stratifying on too many variables

Each stratum needs enough participants to fill complete blocks. Three sites by three age bands is nine sequences, and a study of forty will leave most of them part-full.

Practical tips

• Recruit to a multiple of the block size where you can — that is when the arms come out exactly level.
• Copy the CSV and store it somewhere the recruiting team cannot see before allocation.
• Record the seed only if reproducibility genuinely matters to you; for a real allocation, leave it blank.

Privacy and your data

Your participant ids, arm names and strata stay in your browser. Nothing is uploaded, nothing is stored between visits, and none of it is written into the page address. Analytics records that the tool ran and how many rows it produced — never an id, an arm name or a stratum.

Frequently asked questions

Why not just shuffle?

Because a shuffle of forty into two arms has a real chance of coming out 26–14, and nothing warns you. Block randomisation makes the balance structural: every complete block contains the same number of each arm, so the arms cannot drift apart by more than the final incomplete block.

What block size should I use?

A multiple of your arm count, large enough not to be guessable and small enough to keep the arms close. Four or six with two arms is common. The trade-off is real and the tool does not pretend there is one right answer.

Is this suitable for a clinical trial?

The method is standard, but a trial needs concealed allocation held by somebody independent, a documented procedure and usually a statistician. This produces a sequence in a web page; treat it as a calculator, not as a trial system.

Does randomising properly make my study valid?

No. Randomisation controls allocation. It says nothing about your sample size, your measures, your blinding or your analysis, and a well-randomised study can still answer the wrong question.