nPr for when order matters, nCr for when it doesn't, from the same two numbers.
Updates the moment you change n or r; there is no server round trip involved.
Permutations count ordered arrangements; combinations count unordered selections. nPr = n! ÷ (n−r)!. nCr = n! ÷ (r! × (n−r)!), which is the same as nPr divided by r!. For the default (n = 10, r = 3): nPr = 10 × 9 × 8 = 720; nCr = 720 ÷ 6 = 120.
Both formulas run entirely on factorials, so here are the exact values this calculator's fact() function returns for small n:
18! is the last one JavaScript can hold exactly; see the FAQ below for what happens past it. For a distribution built on top of these same counting rules, see the probability calculator's binomial option.
Both formulas share the same starting point: n!, divided differently depending on whether you care about order. That shared root is why nCr never outgrows nPr, and why a lottery drawing (order doesn't matter, combination) produces a far smaller count than a race's finishing order for the same field of entrants (order matters, permutation) even though both start from the identical n and r.
A 4-digit PIN is a permutation: 1234 and 4321 are different codes even though they use the same digits, so order matters. Picking a 3-person committee from 10 people is a combination: the same three people form the same committee no matter what order you name them in.
The calculator shows "r must be ≤ n" instead of a number. You can't choose more items than exist in the group, ordered or not, so this is treated as an invalid input rather than silently returning zero.
Factorials stay exact through 18! in standard double-precision arithmetic; from 19! on, JavaScript's number type can no longer represent every integer exactly, so results for larger n are a very close floating-point approximation rather than the precise integer.
Because nCr equals nPr divided by r factorial, and r factorial is 1 or larger for any r of 0 or more. Dividing by 1 leaves them equal (true whenever r is 0 or 1); dividing by anything bigger shrinks the count, since combinations collapse every reordering of the same r items into a single count.