User Rating 0.0 ★★★★★

Total Usage 0 times

Category Fun Generators

Participant List

0 entries · 0 unique · 0 invalid

Number of Winners

Options

Allow duplicates Animate reveal

Draw History

No draws yet

Cryptographically Fair Uses crypto.getRandomValues()

Is this tool helpful?

Your feedback helps us improve.

★ ★ ★ ★ ★

About

Running a Twitter/X giveaway without a verifiably fair selection method exposes you to accusations of bias and potential platform policy violations. This tool uses the browser's native crypto.getRandomValues API - the same cryptographic primitive underlying TLS and password generation - to select winners from your participant list. Every draw produces a statistically uniform distribution across all n entries, meaning each participant's probability of selection equals exactly 1n. The tool auto-deduplicates entries, strips formatting artifacts, and validates Twitter handle syntax against the platform's 15-character alphanumeric constraint.

Limitations: this tool cannot verify that accounts are real, active, or followed your rules (retweet, follow, etc.). You must audit winner accounts manually. The draw history is stored locally in your browser for audit purposes but is not externally verifiable - for high-stakes giveaways (prizes above $500), consider screen-recording the draw process. Pro tip: always announce the exact number of entries and winners before drawing to establish transparency.

Formulas

Winner selection uses the Fisher-Yates (Knuth) shuffle algorithm with cryptographically secure random indices. For an array of n participants, the algorithm iterates from index n − 1 down to 1, swapping each element with a uniformly random element from the unprocessed portion:

for i = n − 1 down to 1:
j ← secureRandom(0, i)
swap arr[i] with arr[j]

The first k elements of the shuffled array become the winners, where k is the desired winner count. The probability that any specific participant wins is:

P(win) = kn

Secure random integer generation avoids modulo bias by using rejection sampling. A random 32-bit unsigned integer r from crypto.getRandomValues is accepted only if r < limit, where limit = 2³² − (2³² mod range). This guarantees uniform distribution across the target range.

Where: n = total unique participants, k = number of winners to draw, j = cryptographically random index in range [0, i], P(win) = probability of any single entry winning.

Reference Data

Platform	Handle Format	Max Length	Allowed Characters	Case Sensitive
Twitter/X	@username	15 chars	A - Z, 0-9, underscore	No
Instagram	@username	30 chars	A - Z, 0-9, period, underscore	No
TikTok	@username	24 chars	A - Z, 0-9, period, underscore	No
YouTube	@handle	30 chars	A - Z, 0-9, hyphen, underscore, period	No
Discord	username#0000	32 chars	A - Z, 0-9, period, underscore	Yes

Giveaway Size	Entries	Recommended Winners	Collision Risk (same person)	Draw Time
Micro	10 - 50	1 - 3	None (deduplicated)	< 1ms
Small	50 - 500	1 - 5	None	< 1ms
Medium	500 - 5,000	1 - 10	None	< 5ms
Large	5,000 - 20,000	1 - 20	None	< 10ms
Mega	20,000 - 50,000	1 - 50	None	< 50ms

RNG Method	Entropy Source	Bias	Suitable for Giveaways	Standard
Math.random	PRNG (xorshift128+)	Detectable modulo bias	No	None
crypto.getRandomValues	OS entropy pool	Negligible (< 2⁻¹²⁸)	Yes	W3C Web Crypto
Hardware RNG	Thermal noise / quantum	None measurable	Yes	NIST SP 800-90B
Atmospheric noise	Radio static	None measurable	Yes	random.org

Frequently Asked Questions

The tool uses the Web Crypto API's crypto.getRandomValues, which draws entropy from the operating system's cryptographic random number generator (e.g., /dev/urandom on Linux, BCryptGenRandom on Windows). Unlike Math.random, which uses a deterministic PRNG (xorshift128+) with predictable sequences, CSPRNG output is computationally indistinguishable from true randomness. Additionally, the implementation uses rejection sampling to eliminate modulo bias when mapping random bytes to index ranges.

All entries are automatically deduplicated before the draw. Usernames are normalized to lowercase and stripped of the @ prefix, so @JohnDoe, @johndoe, and johndoe are treated as a single entry. The final unique count is displayed before you draw, so you can verify the deduplication result. This prevents any participant from having a higher probability than 1n.

Yes. After a draw, you can exclude specific winners and redraw from the remaining pool. Each draw is logged in the History panel with a timestamp, the winner list, and the total entry count, creating an audit trail. The original participant list is preserved - only the exclusion list changes between draws.

The tool supports up to 50,000 unique entries. The Fisher-Yates partial shuffle runs in O(k) time where k is the winner count, so even with 50,000 entries and 50 winners, the draw completes in under 50ms. For lists exceeding this limit, split them into batches and run proportional draws per batch.

No. The tool validates handle syntax only - alphanumeric characters and underscores, 1 to 15 characters. It cannot verify account existence, follower status, or retweet compliance without Twitter API authentication. You must manually verify winners against your giveaway rules. Entries that fail syntax validation are flagged and excluded from the draw automatically.

JavaScript's Math.random uses the xorshift128+ algorithm, a pseudo-random number generator seeded from a predictable state. Its output can be reverse-engineered given enough samples, and it exhibits modulo bias when mapped to arbitrary ranges. For a giveaway with 10,000 entries, the bias from naive modulo mapping can skew selection probability by up to 0.002% per entry - small but provable and legally questionable for prize drawings in some jurisdictions.