Is It a Happy Number? The Sum-of-Squares Rule, Explained

A happy number is one of those ideas that sounds like a riddle and turns out to be a tidy little algorithm. Pick a positive integer. Replace it with the sum of the squares of its digits. Do that again to the result. Keep going. If you ever land on 1, the number you started with is happy. If you never reach 1, it is unhappy, and you will be stuck circling the same handful of values forever.

That is the whole rule. No exceptions, no special cases for primes or evens. The interesting part is not the definition but what happens when you actually run the process: every number resolves quickly, and every unhappy number falls into the exact same trap. This post walks through the math, the one worked example everyone learns first, and why the cycle is the key to writing code that never hangs.

The one rule: square the digits, sum them, repeat

Write out the rule precisely so there is no ambiguity. For a number N, take each digit, square it, and add the squares together. That sum becomes your new N. Formally, if N has digits d1, d2, ..., dk, the next value is d1² + d2² + ... + dk².

The single most common mistake is summing the digits instead of squaring them first. Those are different operations and they give different answers. For 19, the digit sum is 1 + 9 = 10, but the sum of squared digits is 1² + 9² = 1 + 81 = 82. Happy numbers only work with the squares. If you ever see a chain that does not match the one below, check whether you skipped the squaring step.

Because squaring keeps the per-digit contribution bounded (the largest single digit, 9, contributes only 81), large numbers collapse fast. A three-digit number can produce at most 3 × 81 = 243, so within a step or two you are always working with small values. That bound is why the process always terminates, which we will get to.

19 is happy: the worked example

Here is the chain everyone traces by hand the first time. Start with 19 and apply the rule step by step:

• 19 → 1² + 9² = 1 + 81 = 82
• 82 → 8² + 2² = 64 + 4 = 68
• 68 → 6² + 8² = 36 + 64 = 100
• 100 → 1² + 0² + 0² = 1 + 0 + 0 = 1

The full trajectory is 19, 82, 68, 100, 1. It reaches 1, so 19 is happy. Four steps, no guessing.

Compare that with 7, another small happy number that takes a slightly longer route: 7 → 49 → 97 → 130 → 10 → 1. Both end at 1, both are happy, but the paths look nothing alike. There is no shortcut that lets you guess the verdict from the starting number's size or shape. You have to walk the chain, which is exactly why the happy number checker prints every step rather than just flashing a yes or no.

If you want a few to verify against, the happy numbers below 100 are 1, 7, 10, 13, 19, 23, 28, 31, 32, 44, 49, 68, 70, 79, 82, 86, 91, 94, 97, and 100. Notice 82 and 68 in that list — they appear because anything on a happy chain is itself happy.

The unhappy numbers all fall into one loop

Now the part that makes the whole thing decidable. Every unhappy number eventually enters the same cycle:

4 → 16 → 37 → 58 → 89 → 145 → 42 → 20 → 4

Once you hit any value in that loop, you are stuck going around it. Take 2 as an example: 2 → 4, and you are already in the cycle. So 2 is unhappy, and so are 3, 5, 6, 8, and 9, which all feed into the same loop within a step or two.

Why does this matter? Because it means there are only two possible fates for any starting number. Either the chain reaches 1, or it joins the 4-cycle. There is no third destination, no mysterious infinite sequence that keeps producing fresh values forever. This was proved by showing that numbers stay bounded under the rule, so the sequence is forced to repeat — and once a value repeats, you are in a cycle. For happy numbers that repeating value is 1 (since 1 maps to 1); for everyone else it is the 4-loop.

That guarantee is what makes a checker possible at all. You are never asking "will this go forever?" — you already know it cannot.

Detecting the cycle in code

This is the classic LeetCode problem 202, and it is a clean exercise because it forces you to think about cycle detection. There are two standard approaches.

The first is a seen-set. You keep a hash set of every value the chain has produced. At each step you compute the next sum of squared digits, then check whether you have seen it before. If the value is 1, return true (happy). If it is already in the set, return false (you found the loop). Otherwise add it and continue. The logic is short:

seen = empty set
while n != 1 and n not in seen:
    add n to seen
    n = sum of squares of digits of n
return n == 1

The second approach uses Floyd's fast-and-slow pointers, the same trick used to find a loop in a linked list. One pointer advances one step at a time, the other advances two. If there is a cycle, the fast pointer eventually laps the slow one and they meet at the same value. If the fast pointer reaches 1 first, the number is happy. This version uses constant extra memory instead of a growing set, which is the usual reason an interviewer asks you to switch to it.

A worked answer for either method should reproduce the 19 chain above exactly. If your code disagrees with the printed trajectory, you almost certainly have a bug in how you extract digits or in the loop's exit condition — a missing set insert, or comparing against the wrong terminal value.

Where I actually use this

I keep this in my back pocket for two situations. The first is debugging the LeetCode solution itself. When my code returns false for a number I am sure is happy, I do not stare at the loop hoping to spot the typo. I run the number through the checker, read the chain, and compare it line by line against what my own loop prints. The mismatch shows up at a single step, and that step tells me whether the bug is in the digit-squaring or the cycle check. It has saved me from off-by-one hunts more than once.

The second is teaching. Happy numbers are the gentlest possible introduction to "we have seen this state before," which is the whole idea behind cycle detection. Showing a class the 4-loop happen on screen — watching 89 lead to 145 lead back around — makes the abstract concept land in a way a slide never does. From there, Floyd's pointers stop feeling like a magic trick and start feeling like an obvious memory optimization. If you enjoy this flavor of number puzzle, the prime factorization tool scratches a similar itch, breaking a number down into its building blocks one step at a time.

A few things worth remembering

Happy numbers are infinite. There is no largest one, no neat closing formula, and they thin out as you climb but never stop appearing. Scanning a range is a fine way to build intuition, but you are always sampling a window, not enumerating a finite set.

And the two failure modes to avoid in your own implementation: do not sum the plain digits (square first), and do not forget the cycle check (a seen-set or fast-and-slow pointers, or your unhappy inputs run forever). Get those two right and the rest is bookkeeping. The process is short, it always terminates, and every step is visible — which is exactly what makes it such a satisfying first algorithm to trace by hand.

---

Made by Toolora · Updated 2026-06-13