Work out the probability of a single event, two independent events, two dependent events, or run Bayes' Theorem to update a probability once new evidence comes in. Pick the mode that matches your problem and you'll get the answer plus the full working, not just a number.
Most probability confusion doesn't come from the math — it comes from not knowing which formula applies. Here's the practical difference between the four cases this page handles.
A single event asks about one outcome out of a fixed set of possibilities: what's the chance of pulling a red card, rolling a 4, or picking the winning raffle ticket. There's nothing to combine. You just count the outcomes you want and divide by all the outcomes that could happen.
Independent events come up when two things happen and neither one changes the odds of the other. Flipping a coin twice is the textbook case — getting heads on the first flip tells you nothing about the second flip. You multiply the two probabilities straight through.
Dependent events are trickier because the first outcome changes what's possible for the second. Draw a card from a deck and don't put it back, and now there are only 51 cards left for the next draw, with one fewer of whatever you just pulled. This is the situation that trips people up in intro stats courses, because it looks like the independent case but isn't.
Bayes' Theorem isn't really about combining two events at all — it's about updating a belief once new evidence shows up. You start with some baseline probability, get a piece of information, and recalculate. Medical testing is the classic example, but it shows up constantly in spam filters, fraud detection, and even courtroom arguments about DNA evidence.
Say a disease affects 1 in 100 people, and a test for it is 95% accurate — meaning it correctly flags 95% of people who have the disease, and only wrongly flags 5% of people who don't. Someone tests positive. What's the actual chance they have the disease?
Most people guess somewhere around 90–95%, because that's the number attached to the test. The real answer is closer to 16%.
Here's why. Imagine 10,000 people take the test. Since 1% actually have the disease, that's 100 people, and the test correctly flags 95 of them. But among the 9,900 healthy people, 5% still test positive by mistake — that's 495 false alarms. Add those together and 590 people test positive in total, but only 95 of them are actually sick. 95 divided by 590 comes out to roughly 16%.
This is exactly what Bayes' Theorem calculates, and it's the reason doctors run a second, different test before treating a positive result as conclusive when the underlying condition is rare. Try the numbers above in the Bayes' Theorem calculator further up the page and you'll get the same 16% figure the long way.
Treating dependent events as independent. Drawing two cards "at random" from a deck without replacement is dependent — the second draw has one fewer card to choose from, and one fewer of whatever came out first. Multiplying the two probabilities as if nothing changed gives a number that's close but wrong.
Forgetting the subtraction in the addition rule. If P(A) = 0.6 and P(B) = 0.7, simply adding them gives 1.3 — an impossible probability. The overlap between A and B has been counted twice and needs to come back out.
Reading "95% accurate" as "95% chance you have it." As the worked example above shows, those are two completely different numbers once you account for how common or rare the thing being tested for actually is.
Confusing P(A|B) with P(B|A). The probability of rain given clouds is not the same number as the probability of clouds given rain. Mixing these up is called the base rate fallacy, and it's the single most common error in real-world probability reasoning — juries, journalists, and even doctors make it regularly.
Independent-event math shows up any time you're stacking odds across repeated, unrelated trials — a manufacturing line checking the chance that two separate machines both fail in the same shift, or a game designer calculating the odds of a rare drop happening twice in a row.
Dependent-event calculations are behind card games, sampling without replacement in quality control (pulling items from a batch to inspect, where each pull changes what's left), and any situation involving a shrinking pool of possibilities.
Bayes' Theorem sits underneath spam filtering (how likely is this email to be spam, given it contains the word "free"?), medical diagnosis, search-and-rescue probability models, and legal arguments involving DNA match statistics — the same "how rare is the underlying condition" logic from the medical test example applies almost unchanged in a courtroom.
P(A∩B) is both things happening together — think of it as the overlap if you drew A and B as two circles. P(A∪B) is either one happening, or both — the combined area of the two circles. Mixing these two up is the single most common notation error in intro probability.
Because probability is a proportion of outcomes out of a total, and you can't have a negative number of outcomes or more outcomes than exist. If your calculation lands outside 0 to 1, it's a signal to check your inputs — most often it means you added two probabilities without subtracting their overlap.
Test it: does P(A∩B) equal P(A) × P(B)? If it does, they're independent. In practice, most independence assumptions come from how the scenario is described — separate coin flips, separate dice, drawing "with replacement" — rather than from checking the math each time, since you'd need to already know P(A∩B) to test it.
No, and this trips up a lot of students. P(A∩B) means "the probability of A and B both happening" — it's one single number. P(A) ∩ P(B) doesn't really mean anything in standard notation, since you can't take the intersection of two numbers. If you see this written somewhere, it's shorthand (or a typo) for P(A∩B).
No — this is a common slip. 1 in a million is 0.0001 as a decimal, which is 0.0001 × 100 = 0.01%, not 0.0001%. When converting between "1 in X" and percentages, divide 1 by X first, then multiply by 100.