Why is the answer 50% at only 23 people — that can't be right?

It is. The trick is what you're counting. We're not asking "does anyone share MY birthday" (that grows slowly — you'd need ~253 people for 50%). We're asking "do ANY two of N people collide". With 23 people that's 23×22/2 = 253 pairs of possible collisions — almost the same number — and 50% odds shows up at exactly the same place. Same number, different question.

What's the exact formula?

P(at least one shared birthday) = 1 − 365! / ((365 − N)! × 365^N). Equivalent and easier to compute: 1 − Π_{k=0..N−1} (365 − k) / 365. We compute it in log space to stay numerically stable for N up to 365.

Does it handle Feb 29?

No — we assume 365 equally likely days. Including Feb 29 (with weight 1/4) shifts the answers by less than 0.1 percentage points for any group size below 100. For the curiosity-driven use case the classic 365-day version is the right one to teach.

Are real birthdays really uniformly distributed?

No, they're slightly clumped. In US data September births are over-represented (count back ~9 months from December holidays). The clumping makes real-world collisions a tiny bit more likely than the math says — roughly 1–2 percentage points higher in a group of 23. The paradox gets even stronger in reality, not weaker.

How does the 50% threshold change for different "year" sizes?

It scales as roughly √(2·days·ln 2) ≈ 1.177·√days. So for 365 days you get ≈ 23. For 100 "days" you get ≈ 12. For a hash with 2^32 possible outputs, you get ≈ 77,000 — which is why MD5 collisions are practical to find. Same math, same paradox.

Where does the birthday paradox actually matter in real life?

Three places. (1) Classroom demo for probability — easiest "counterintuitive" example to explain. (2) Cryptographic hash collisions — the "birthday attack" is exactly this math applied to hash outputs, and it sets the security parameter for SHA-2 / SHA-3. (3) Hash table sizing — when N keys land in M slots, the chance of a collision crosses 50% at N ≈ 1.177·√M, which is why you size hash tables generously.

Why does the curve climb so fast between 10 and 40?

Because the number of pairs grows as N(N−1)/2 — quadratic in N. Doubling the group from 10 to 20 quadruples the pairs (45 → 190). Every new person adds a collision-chance with every existing person, so the probability of "at least one collision somewhere" piles up much faster than intuition expects from "one more person".

Settle the "no way it's 23" classroom bet before the lesson

You're teaching probability and want the hook. Before class, set N to 23 and screenshot the 50.7% result, then set N to 30 (70.6%) and N to 50 (97.0%). Walk in, ask 25 students to guess how many people you need for a coin-flip chance, watch them say "180" or "183", then reveal 23. The classic-cases table gives you all the numbers on one screen so you never fumble a figure mid-demo.

Size a hash table before keys start colliding

You have ~1000 keys and a 1,000,000-slot table and wonder if collisions are a real risk. The √ rule says 50% collision odds hit at N ≈ 1.177·√1000000 ≈ 1177 keys, so at 1000 you're already near a coin flip. Plug the day-count analogy in your head, confirm against the curve's quadratic climb, and decide to grow the table to 4M slots so collisions stay rare.

Explain a "birthday attack" to a teammate in five minutes

A junior dev asks why a 64-bit hash isn't enough for collision resistance. Open the tool, show that 50% odds scale as 1.177·√days, then map "days" to 2^64 outputs: collisions become likely around 2^32 ≈ 4.3 billion samples, not 2^64. The same curve that explains 23 people explains why you need 256-bit hashes. The visual click lands faster than a whiteboard derivation.

Check the odds for your own 28-person team standup

Someone on your 28-person team claims two people share a birthday and you want to know if that's surprising. Set N to 28 and read 65.4% — so it's actually more likely than not. The complementary "everyone unique" number (34.6%) tells you a no-collision team is the rarer case. You stop being surprised and start expecting the overlap in any group past 23.

Birthday Paradox Calculator — Probability, 50% Threshold & Curve

Birthday paradox calculator — see the probability of shared birthdays in a group of N people, visualized step by step.

Runs locally
Category Calculator
Best for Getting a realistic range before a purchase, plan, workout, or schedule decision.

Group size N (people)

How many people are in the room?

Probability that at least two share a birthday

50.7%

Probability that everyone has a different birthday

49.3%

Pairs in the group:253= N(N-1)/2

Classic 50% threshold

Only 23 people are needed for the odds of a shared birthday to cross 50%.

Probability curve — 1 to 100 people

P(shared) 50% mark Your N

Classic comparisons

People	P (shared)	P (all unique)
5	2.71%	97.3%
10	11.7%	88.3%
23★	50.7%	49.3%
30	70.6%	29.4%
50	97.0%	2.96%
70	99.9%	0.08%
100	>99.99%	<0.01%

The formula — why the answer feels wrong

The trick: we don't ask "what's the chance someone shares MY birthday" (that grows slowly). We ask "what's the chance ANY two of N people collide" — and the pairs grow as N(N-1)/2. With 23 people that's 253 pairs already — enough to push the odds past 50%.

Step 1Easier to compute the opposite: P(all N birthdays are different).
Step 2Person 1: 365/365. Person 2: 364/365. Person 3: 363/365. … Person N: (365-N+1)/365.
Step 3Multiply them all: P(unique) = 365! / ((365-N)! × 365^N).
Step 4Answer: P(at least one shared) = 1 - P(all unique).

Assumes 365 equally likely birthdays (ignores Feb 29) and that birthdays are independent. Real data is slightly clumped — September births are over-represented — which makes collisions a hair more likely than the math says.

What this tool does

Free online birthday paradox calculator. Enter a group size N (1–365) and instantly see the probability that at least two people share a birthday, the complementary probability that everyone is unique, and the classic 50% threshold (N = 23 — yes, really). The interactive SVG curve plots probability for every group size from 1 to 100, marks the 50% line, and highlights your own N. A classic-cases table compares 5 / 10 / 23 / 30 / 50 / 70 / 100 people side by side, and a four-step derivation walks through the formula P(shared) = 1 − 365! / ((365−N)! × 365^N) — built up from "it's easier to count pairs than to count collisions". Includes the pair-count N(N−1)/2 so you can see why the odds shoot up so fast. 100% client-side: nothing leaves the browser.

Tool details

Input: Numbers; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy + Preview; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Shareable URL state; Key settings are encoded in the URL so another person can reopen the same setup.
Performance budget: Initial JS <= 12 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Calculator · Student; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How Birthday Paradox Calculator fits into your work

Use it for fast estimates, comparisons, and planning numbers before you make the final call.

Calculation jobs

Getting a realistic range before a purchase, plan, workout, or schedule decision.
Comparing scenarios by changing one input at a time.
Turning rough assumptions into a number you can discuss.

Calculation checks

Double-check units, dates, rates, and rounding assumptions.
Treat health, finance, tax, and legal outputs as planning aids, not professional advice.
Save the inputs that produced an important result so you can reproduce it later.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Settle the "no way it's 23" classroom bet before the lesson
You're teaching probability and want the hook. Before class, set N to 23 and screenshot the 50.7% result, then set N to 30 (70.6%) and N to 50 (97.0%). Walk in, ask 25 students to guess how many people you need for a coin-flip chance, watch them say "180" or "183", then reveal 23. The classic-cases table gives you all the numbers on one screen so you never fumble a figure mid-demo.
Size a hash table before keys start colliding
You have ~1000 keys and a 1,000,000-slot table and wonder if collisions are a real risk. The √ rule says 50% collision odds hit at N ≈ 1.177·√1000000 ≈ 1177 keys, so at 1000 you're already near a coin flip. Plug the day-count analogy in your head, confirm against the curve's quadratic climb, and decide to grow the table to 4M slots so collisions stay rare.
Explain a "birthday attack" to a teammate in five minutes
A junior dev asks why a 64-bit hash isn't enough for collision resistance. Open the tool, show that 50% odds scale as 1.177·√days, then map "days" to 2^64 outputs: collisions become likely around 2^32 ≈ 4.3 billion samples, not 2^64. The same curve that explains 23 people explains why you need 256-bit hashes. The visual click lands faster than a whiteboard derivation.
Check the odds for your own 28-person team standup
Someone on your 28-person team claims two people share a birthday and you want to know if that's surprising. Set N to 28 and read 65.4% — so it's actually more likely than not. The complementary "everyone unique" number (34.6%) tells you a no-collision team is the rarer case. You stop being surprised and start expecting the overlap in any group past 23.

Common pitfalls

Asking "does anyone share MY birthday" instead of "do any two collide" — the first needs ~253 people for 50%, the second only 23. The tool answers the second; don't expect it to match the first.
Assuming Feb 29 and clumped real birthdays break the result. They shift 23-person odds by only 1–2 points, and clumping makes collisions more likely, not less, so the paradox holds.
Thinking the curve is linear and eyeballing "double the people, double the odds". Pairs grow as N(N−1)/2, so 10→20 people quadruples collision chances (45→190 pairs); read the actual curve, don't extrapolate.

Privacy

This calculator runs entirely in your browser. The only input is the group size N, a plain number you type in — no names, no actual birthdays, nothing personal. N is reflected in the URL so you can share a link that reproduces your result (e.g. ?n=23), but that single number is all the link carries. Nothing is uploaded, logged, or sent to any server.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Browse all tools for this role

Birthday Paradox Calculator — Probability, 50% Threshold & Curve

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How Birthday Paradox Calculator fits into your work

Calculation jobs

Calculation checks

Good next steps

Real-world use cases

Settle the "no way it's 23" classroom bet before the lesson

Size a hash table before keys start colliding

Explain a "birthday attack" to a teammate in five minutes

Check the odds for your own 28-person team standup

Common pitfalls

Privacy

FAQ

Running Pace Calculator

Scientific Calculator

Percentage Calculator

Math Formula Reference

Random Number Generator

Aspect Ratio Calculator

IELTS Band Calculator

Number Base Converter

College Major Matcher (Holland RIASEC, 40 Questions)

24-Point Solver & Game

555 Timer Calculator

A1C to Blood Glucose Calculator