Random order generator

Paste a list and get it back in a genuinely random order — numbered, copyable, and saved in your browser for next time.

How it works

Shuffling sounds like the kind of thing that is hard to get wrong, and it is one of the easiest things in this whole category to get wrong. The method used here is the Fisher–Yates shuffle: walk the list from the last position to the first, and at each step swap the current entry with one chosen from the positions at or before it. Every one of the possible orderings comes out equally often. For a list of ten names there are 3,628,800 possible orders, and this method can produce all of them with the same frequency.

The randomness itself comes from crypto.getRandomValues, the generator built into your browser for security work. There is one wrinkle worth naming, because it is the part almost every implementation skips. That generator hands back a number in a range of 2³² values. If you want a number from 0 to 9 and you simply take the remainder, the first six values come up very slightly more often than the rest, because 2³² does not divide evenly by ten. The fix is to discard the small leftover block and draw again. That is what this tool does, and it is why a draw here is uniform rather than merely close.

We are careful not to overstate the case. You will sometimes read that Math.floor(Math.random() * n) is broken. It is not. Its skew sits at around one part in nine quadrillion, which is not a defect in a tool that shuffles a class register. We use the other generator because it costs nothing and lets us describe the method precisely, not because the ordinary one would give you a bad shuffle.

The mistake that is genuinely worth avoiding

There is one shuffling method that really does fail, and it is the most widely copied line in this entire category — sorting a list with a comparison function that answers at random. It looks elegant and it produces a plausible-looking result every single time, which is exactly why it survives review. But a sorting algorithm calls its comparison function a fixed number of times in a fixed pattern, so answering at random does not produce a random order. It produces whatever order that particular sorting algorithm happens to fall into, and some orderings come up many times more often than others.

This is not a theoretical concern. Running both methods over the same list, with the same source of randomness, for 240,000 shuffles each: Fisher–Yates put every possible ordering within 2.54% of its expected share — the same figure on every browser engine we test on — while the sort-based version was off by many times that on its worst ordering, by an amount that changes with the engine, because the sorting algorithm is what ends up deciding the result. The full measurement, both figures and what we deliberately do not claim are on the fairness page.

Worked examples

Deciding who presents when

Eight people have prepared something for a review meeting and nobody wants to go first. Paste the eight names, shuffle, and read the numbered result out. The useful part is not that it is random, it is that it is visibly random — nobody has to trust that you did not put your own name last. Save it as “Design review” and the same eight names are waiting the following fortnight.

Turn order for a game

Board games often start with an argument about who goes first. A shuffled list settles it in about four seconds, and unlike rolling for it, it gives you the full order in one step rather than resolving ties.

A fair rota

Chores, on-call weeks, the order people present at a standup. Shuffling once and then rotating that order is fairer than shuffling every time, because a fresh shuffle each week means somebody can land in the same unpopular slot three weeks running purely by chance.

Randomising a queue

Thirty entries for a giveaway, and you want to work through them in an order nobody could have arranged in advance. Shuffle the list, copy the numbered result, and paste it wherever you are keeping the record.

Questions people actually ask

Are my names sent anywhere?

No. The shuffle happens inside your browser, and the lists you save are stored on your own device using your browser's local storage. Nothing is uploaded and no server here ever sees a name. You can check that yourself: open your browser's developer tools, switch to the network tab, and shuffle. Nothing goes out.

What happens to duplicate names?

They are kept. Two people in a group really can share a first name, and quietly merging them would remove somebody from the running order without telling you. If you paste “Ana” twice, you get two entries.

Will my list still be here tomorrow?

Yes, as long as you use the same browser on the same device and do not clear your site data. That is the point of the save button. Clearing your browsing data will remove saved lists, because they live in your browser rather than in an account.

Can I shuffle the same list again?

Press the button again and you will get an independent new order. Each shuffle is unrelated to the last one — a name that came first is exactly as likely to come first again.

Limitations, stated plainly

• Saved lists are tied to one browser. They do not follow you to your phone, because there is no account and nothing is stored on a server. That is a deliberate trade: the privacy claim above is only true because there is nowhere else for the data to be.
• Clearing site data clears your lists. There is no copy elsewhere to restore from.
• Very long lists are capped. Beyond the limit the tool tells you how many entries it found and how many it is using, rather than silently working with a shorter list.
• Private or incognito windows forget everything when the window closes, and some privacy settings block storage entirely. The shuffler still works; the saving does not, and the page says so rather than failing quietly.