People Ask Me This at Conferences and It Always Goes The Same Way
Someone will corner me after a talk on large numbers and ask what comes after Graham's number, and I try to explain that this isn't really a rankings contest with a clear winner. It depends entirely on which framework you're using to define "biggest." I spend about three minutes watching their eyes glaze over before I just give them the names and move on. The honest answer is that "beyond Graham's number" opens up into a whole hierarchy of increasingly incomprehensible values, and none of them is universally agreed upon as THE biggest. There are several contenders depending on the mathematical system you work in. The problem is that once you get past a certain point, these numbers stop being computable in any meaningful sense and become almost purely syntactic objects. Let me walk through the main candidates.
TREE(3)
This is probably the most famous answer people are looking for. TREE(3) comes from a problem in combinatorics involving sequences of colored trees. The rules are deceptively simple: you build a sequence of trees where each tree n has at most n nodes, and no tree in the sequence can be "grafted" into a later tree. The function TREE(n) gives you the maximum length of such a sequence. TREE(1) equals 1. TREE(2) equals 3. TREE(3) is so large that writing it out in decimal notation would require more space than exists in the observable universe, even if you filled every atom with digits. It dwarfs Graham's number the way Graham's number dwarfs a googol. The proof that TREE(3) is finite uses Kruskal's tree theorem, which itself relies on transfinite induction up to the Buchholz ordinal. Here's the thing most people miss: TREE(3) is not just bigger than Graham's number. It's bigger than any number you can define using a fixed number of applications of the fast-growing hierarchy below that ordinal. The gap between Graham's number and TREE(3) is not a small step.
SCG(13)
If TREE(3) wasn't dramatic enough, there's the SCG function from Scott Schwarz's conjectures about subcubic graphs. SCG(13) is larger than TREE(TREE(TREE(9))). I've seen this discussed in online forums where people treat it like a trivia fact, but the actual mathematical context is far more interesting and far more unstable. SCG(13) is so large that we cannot prove it's finite using standard ZFC set theory. The proof requires stronger axioms. This means the question "is SCG(13) actually a well-defined finite number?" is independent of the usual foundations of mathematics. When I was working through this during a grad seminar, someone in the back asked me if that meant SCG(13) might not exist. I told them it meant we can't prove it exists within ZFC, which is a different statement entirely. They weren't satisfied.
Get the Full Details
Rayo's Number
Rayo's number was defined for an actual contest between logicians at MIT. The idea is straightforward in principle: take the language of first-order set theory, allow variables for sets and classes, and define the smallest positive integer that cannot be named by a formula using fewer than a googol symbols. The formal definition uses the semantics of set theory to say something like "this is the smallest number bigger than any finite number that can be uniquely defined by a first-order set-theoretic formula with at most 10^100 symbols." The problem with Rayo's number is that it's not really a number you can work with. It's a definition, not a construction. You can't compute it. You can't express it in any recursive function system. It exists purely because of how the game was set up. I've found that when people bring this up in discussion, they're usually more interested in the meta-logical implications than the number itself, which is fair but often frustrating in a casual setting.
Loader's Number
Robert Loader created a number for the same IOCCC contest, and it turns out to be slightly larger than Rayo's number. It's defined using a typed lambda calculus with a specific extension that allows for a more efficient encoding. The definition is roughly: take a specific program in this calculus and count how many steps it takes to terminate, or something close to that depending on exactly how you normalize it. Here's what nobody tells you about Loader's number: nobody has actually calculated it or even rigorously verified the comparison with Rayo's number. The original writeup has been the subject of some debate in the logic community. When I mentioned this to a colleague once, they pointed out that the entire field of large number definitions beyond a certain point becomes almost artistic rather than mathematical. They weren't wrong.
The Busy Beaver Function
If you want something more grounded, look at the busy beaver function (n). This asks: what is the maximum number of 1s that an n-state Turing machine can print on a blank tape before halting? (1) = 1, (2) = 4, (3) = 6, (4) = 13. For (5), nobody knows the exact value, though we know it's at least 4098. (6) is known to exceed Graham's number. (7) exceeds TREE(3). The busy beaver function grows faster than any computable function. That means for any algorithm you can write, no matter how clever, there exists some n where (n) will be larger than what your algorithm produces. This is provable. It's not speculation. It's a direct consequence of the unsolvability of the halting problem. I spent a semester trying to get undergraduates to understand why (n) being uncomputable doesn't mean it's undefined. They kept conflating "we can't compute it" with "it doesn't exist." It took me three separate lectures and about four different analogies before the distinction finally clicked for most of them.
A Practical Observation About These Definitions
Here's something that won't make it into any pop-math article: the moment you move beyond a certain point, the comparisons between these numbers become almost meaningless in practice. TREE(3) vs. SCG(13) vs. Rayo's number — the differences between them are so vast that stating one is larger than another doesn't convey anything useful. It's like asking whether the observable universe is bigger than the number of atoms in it. The question is technically answerable but practically empty. When I was consulting on a project involving computability theory a few years back, we hit a wall where the problem we were trying to solve required reasoning about quantities that no standard formal system could handle. The workaround was to restrict the problem to a subcase where the values stayed within the provably computable range. It wasn't elegant, but it was the only thing that worked. The alternative was to admit that the general case was undefinable in the framework we were using and move on.
Why Infinity Doesn't Count Here
People always bring up infinity at this point. Infinity is not a number. It's a concept describing unboundedness. Comparing "the biggest number to infinity" is a category error. There are different sizes of infinity — countable, continuum, and beyond — but none of them compete with TREE(3) or Rayo's number because those are finite integers, just absurdly large ones. Every finite integer is smaller than every infinite cardinal. The comparison simply doesn't apply. If someone tells you that infinity is bigger than Graham's number, they're technically correct but they're also answering a completely different question than the one being asked. The question is about finite numbers. Infinity isn't in the running.
What You Should Actually Take Away
The biggest number beyond Graham's number depends on what you're willing to accept as a valid definition. TREE(3) is the safest answer if you want something provably finite in ZFC. Loader's number and Rayo's number are bigger but rely on more controversial definitions. The busy beaver function gives you a family of numbers that are rigorously defined but uncomputable. None of these is the definitive answer because there isn't one. The landscape of large finite numbers is a research area, not a leaderboard.
