Complete Guide
How Leap Years Actually Work (and Why 1900 Wasn't One)
The rule everyone half-remembers
Most people can recite the first half of the leap year rule without hesitation: every four years, add an extra day to February. It's taught early, it's simple, and it's wrong on its own โ or more precisely, incomplete in a way that quietly breaks any calendar calculation that relies on it without the rest of the rule.
The actual Gregorian calendar rule, the one virtually every civil calendar in the world uses today, has three tiers, not one: a year is a leap year if it's divisible by 4; except if it's also divisible by 100, in which case it is NOT a leap year; except if it's also divisible by 400, in which case it IS a leap year after all. Three simple conditions, layered to correct for each other, and the entire reason the third tier exists is to fix an error the first two tiers would otherwise introduce.
Why the simple rule isn't good enough
Earth's actual orbital period โ the real time it takes to circle the Sun once โ is approximately 365.2422 days. Not 365, and not exactly 365.25 either. That difference between the actual solar year and either possible calendar approximation is the entire reason this whole system exists.
If you used the simple "every four years" rule with no exceptions (which is exactly what the Julian calendar did, introduced by Julius Caesar in 46 BC), you'd add a leap day 100 times every 400 years, giving an average year length of exactly 365.25 days. That's closer to reality than a flat 365, but it still overshoots the true 365.2422 by about 0.0078 days per year โ roughly 11 minutes. Eleven minutes doesn't sound like much. Multiplied across centuries, it adds up fast: about three-quarters of a day drifts every century, or roughly one full day every 128 years.
By the 16th century, this accumulated drift had become a real, practical problem โ not an abstract one. The Julian calendar had drifted about 10 days out of alignment with the actual seasons since its introduction, which mattered enormously to the Catholic Church because it threw off the calculated date of Easter, which is defined relative to the spring equinox. Pope Gregory XIII commissioned a fix, implemented in 1582: the Gregorian calendar, which kept the simple "every 4 years" rule but added the century-year exception (skip leap years in century years, except when divisible by 400) specifically to correct that drift going forward.
Doing the math on the correction
Under the Gregorian rule, out of every 400 years, you get 100 candidate leap years (every year divisible by 4), minus the 4 century years in that span that would normally qualify (year 100, 200, 300, 400 relative to the start of the cycle), plus adding back the ONE of those four that's divisible by 400. That's 100 โ 4 + 1 = 97 leap years every 400 years, not 100.
That gives a 400-year cycle of 400 ร 365 + 97 = 146,000 + 97 = 146,097 days. Divide that by 400 to get the average Gregorian year length: 146,097 รท 400 = 365.2425 days exactly. Compare that to the true solar year of approximately 365.2422 days โ the Gregorian calendar now overshoots by only about 0.0003 days per year, or roughly one day every 3,300 years. That residual error is so small that no further correction has been needed since 1582, and none is expected to be needed for a very long time yet.
This is also why 1900 was not a leap year (divisible by 100, not by 400), why 2000 was a leap year (divisible by 400), and why 2100, 2200, and 2300 will all be skipped, with the next century leap year not arriving until 2400. If you only remember "every 4 years," every one of those specific years will trip you up.
Where this quietly shows up in software
Leap year bugs are a genuinely recurring category of real software defects, not a hypothetical trivia point. A surprisingly common pattern: a developer implements "is this a leap year" as simply `year % 4 === 0` and ships it, because it passes every test case they happened to think of โ which almost never includes a century year, since those are comparatively rare in any given test suite's date range. The bug lies dormant until the code runs against a year like 1900 or 2100, at which point it silently produces a wrong result: treating a 365-day year as if it had 366 days, or vice versa.
The consequences cascade in ways that aren't always obvious. A wrong leap-year determination throws off February's day count, which throws off the ordinal day-of-year number for every date from March 1st onward that year, which can throw off scheduling systems, billing cycles, and anything else built on top of an assumption that a given date's day-of-year number is correct. It also affects whether a specific year needs a 53rd ISO-8601 week (a year needs one specifically when January 1st falls on a Thursday, or falls on a Wednesday in a leap year) โ get the leap-year check wrong, and you can get the week-53 determination wrong too, compounding the error into a completely different part of the calendar system.
The weekday connection: why the calendar repeats every 400 years
Here's a genuinely elegant consequence of the exact numbers above: 146,097, the total number of days in a full 400-year Gregorian cycle, happens to be exactly divisible by 7 (146,097 รท 7 = 20,871, with no remainder). That's not a coincidence baked in by design from the start so much as a fortunate mathematical property of how the numbers work out โ but it has a real, practical consequence: the entire pattern of which weekday falls on which date repeats exactly, with zero drift, every 400 years.
That means if your birthday fell on a Tuesday this year, and you could somehow ask the same question exactly 400 years from now, the answer would be the same: Tuesday. No calendar system before the Gregorian reform had this clean a repeat cycle, because the Julian calendar's uncorrected leap-year rule doesn't produce a total day count divisible by 7 over any similarly clean interval.
Within a single lifetime, the weekday of a fixed date (like a birthday) doesn't shift by a consistent, predictable amount each year โ it shifts forward by one weekday in most years, but by two weekdays whenever a leap day (February 29) falls between the two occurrences you're comparing. This is exactly the mechanism the Next Birthday Weekday Finder and Perpetual Calendar tools compute directly, and it's also the underlying reason a simpler 28-year weekday-repeat pattern (which does hold under the Julian calendar's uniform rule) breaks under the Gregorian calendar whenever a skipped century year falls inside the span being checked.
How other calendars solve the same underlying problem differently
It's worth stepping back to see that the Gregorian calendar's approach โ a leap DAY inserted on a fixed schedule โ is just one way of solving a problem every solar calendar faces: a year isn't a whole number of days, so some correction is needed. The Islamic Hijri calendar sidesteps the problem entirely by not attempting the correction at all โ it's a purely lunar calendar, with no leap-day mechanism, which is exactly why its dates drift steadily through the Gregorian seasons over a roughly 33-year cycle rather than staying anchored to a fixed time of year. The Hebrew calendar takes yet another approach: rather than a leap DAY, it periodically inserts an entire extra leap MONTH, on a defined 19-year cycle, which keeps its lunar-based months roughly anchored to the same solar season year after year despite the calendar fundamentally being built around lunar, not solar, months. Each solution reflects a different set of priorities about what the calendar is actually meant to track.
A mental checklist for verifying any specific year by hand
Given how often the incomplete "every 4 years" version of this rule gets applied by mistake, it's worth having a simple, repeatable mental checklist. Step one: does the year divide evenly by 4? If not, stop โ it's not a leap year. Step two, only if step one passed: does the year also divide evenly by 100? If not, stop โ it IS a leap year. Step three, only if step two passed: does the year also divide evenly by 400? If yes, it's a leap year after all; if no, it's not. Running this against a handful of test cases โ 2024 (yes, no โ leap year), 1900 (yes, yes, no โ not a leap year), 2000 (yes, yes, yes โ leap year), 2100 (yes, yes, no โ not a leap year) โ makes the rule's three tiers concrete rather than abstract, and specifically exercises the century-year cases that a naive "every 4 years" shortcut gets wrong.
Practical takeaways
If you're building or checking any date-related calculation, the leap-year rule is worth getting exactly right rather than approximately right, because "approximately right" fails silently and rarely on ordinary years, then fails loudly and unpredictably on century years. The correct, complete test is: divisible by 4 AND (not divisible by 100 OR divisible by 400) โ all three conditions matter, and dropping any one of them reintroduces an error at the exact years people are least likely to test.
On this site, the Leap Year Checker applies exactly this rule and is the single shared foundation for several other tools: Days in a Month (specifically February's count), Days in a Year (365 vs. 366), the Week Number Calculator's 53-week-year determination, and the weekday-shift math behind the birthday and perpetual-calendar tools. Getting this one rule right, once, in one place, is exactly why those tools stay consistent with each other rather than each reimplementing โ and potentially each slightly mis-implementing โ the same three-tier logic independently.
A quick sanity check anyone can do by hand
You don't need software to check whether a specific year is a leap year โ the three-tier rule is simple enough to apply mentally in a few seconds. Take the year, check if it divides evenly by 4 (if not, it's not a leap year, and you're done). If it does divide by 4, check if it also divides by 100 (if not, it IS a leap year). If it does divide by 100, check if it also divides by 400 (if yes, leap year; if no, not a leap year). Try it on 2024 (divides by 4, doesn't divide by 100 โ leap year, correct), 1900 (divides by 4 and by 100, doesn't divide by 400 โ not a leap year, correct), and 2000 (divides by 4, by 100, AND by 400 โ leap year, correct).
How other calendar systems handle the same underlying problem
The Gregorian calendar's leap-year correction is one solution to a universal problem every solar calendar has to solve: a calendar year measured in whole days can never perfectly match Earth's actual orbital period, so every system needs some mechanism to keep the seasons from slowly drifting. Other calendar systems solve it differently. The Islamic Hijri calendar is purely lunar and simply doesn't correct for it at all, so its observances cycle slowly through every possible season across roughly three decades rather than staying pinned to one. The Hebrew calendar splits the difference, staying lunisolar by bolting an entire extra month onto seven years out of every nineteen, keeping its festivals locked to roughly the same season indefinitely despite still counting lunar months underneath.