I expected the 2026 World Cup bracket to be a sorting problem.
It turned out to be a sorting problem plus a lookup table.
I recently worked on a small World Cup 2026 bracket project, and the strangest part was not building the knockout bracket itself. It was handling the third-placed teams.
The new format has:
- 48 teams
- 12 groups
- 24 teams qualifying as group winners and runners-up
- 8 more teams qualifying as the best third-placed teams
- a new Round of 32
At first, this sounded straightforward.
Rank the third-placed teams, take the best 8, then put them into the knockout bracket.
But the last step is where it gets weird.
Ranking third-placed teams is the easy part
Once every group has a table, each group gives you one third-placed team.
That gives you 12 third-placed teams.
From there, the basic ranking can be represented as a normal sorting problem:
type GroupId =
| "A" | "B" | "C" | "D"
| "E" | "F" | "G" | "H"
| "I" | "J" | "K" | "L";
type TeamStanding = {
teamId: string;
group: GroupId;
position: number;
points: number;
goalDifference: number;
goalsFor: number;
fairPlayPoints: number;
};
A simplified ranking function might look like this:
function rankThirdPlacedTeams(teams: TeamStanding[]) {
return [...teams].sort((a, b) =>
b.points - a.points ||
b.goalDifference - a.goalDifference ||
b.goalsFor - a.goalsFor ||
a.fairPlayPoints - b.fairPlayPoints
);
}
This is not the complete official tie-breaker system, but it shows the shape of the problem.
You filter the third-placed teams:
const thirdPlacedTeams = groupTables
.map(group => group.standings.find(team => team.position === 3))
.filter(Boolean);
Then you take the top 8:
const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);
So far, this still feels like a normal algorithm problem.
But then comes the awkward part.
The bracket position is not simply “best third-place team goes here”
My first assumption was that the best third-placed team would go into one slot, the second-best into another slot, and so on.
That is not how it works.
The Round of 32 matchup depends on which groups the qualifying third-placed teams came from.
For example, if the qualifying third-placed teams come from groups:
["C", "D", "E", "F", "G", "I", "K", "L"]
that combination maps to one specific set of Round of 32 positions.
If the qualifying groups are:
["B", "D", "E", "F", "G", "I", "K", "L"]
that maps differently.
So the key is not only ranking the third-placed teams.
The key is identifying the set of groups they came from.
With 12 groups and 8 third-placed teams qualifying, the number of possible group combinations is:
C(12, 8) = 495
That means there are 495 possible sets of qualifying third-placed groups.
This is where the implementation stops being a clean formula and becomes a data problem.
Turning the qualified groups into a key
The simplest way I found to model this was to turn the list of qualifying third-place groups into a stable key.
function getThirdPlaceCombinationKey(teams: TeamStanding[]) {
return teams
.map(team => team.group)
.sort()
.join("");
}
So if the qualified third-placed teams came from groups C, D, E, F, G, I, K, and L, the key becomes:
"CDEFGIKL"
This key can then be used to look up the official mapping for the Round of 32.
const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);
const combinationKey = getThirdPlaceCombinationKey(qualifiedThirds);
Now we can use that key to answer the real question:
Where does each third-placed team go in the bracket?
Representing the mapping as data
Instead of trying to derive the Round of 32 slots every time, I treated the official scenarios as a lookup table.
A simplified version looks like this:
type RoundOf32Slot =
| "1A" | "1B" | "1D" | "1E"
| "1G" | "1I" | "1K" | "1L";
type ThirdPlaceSource = `3${GroupId}`;
type ThirdPlaceMapping = Record<RoundOf32Slot, ThirdPlaceSource>;
const thirdPlaceSlotMap: Record<string, ThirdPlaceMapping> = {
CDEFGIKL: {
"1A": "3E",
"1B": "3G",
"1D": "3I",
"1E": "3D",
"1G": "3F",
"1I": "3C",
"1K": "3L",
"1L": "3K",
},
BDEFGIKL: {
"1A": "3E",
"1B": "3G",
"1D": "3I",
"1E": "3D",
"1G": "3F",
"1I": "3B",
"1K": "3L",
"1L": "3K",
},
// ...493 more combinations
};
The exact values need to come from the official table, but the structure is the important part.
The code is not trying to be clever.
It is just making the official tournament rules usable inside an app.
Filling the actual teams into the bracket
Once the mapping is known, the rest is more mechanical.
For each Round of 32 slot, find the third-placed team from the mapped group.
function getThirdPlacedTeamFromGroup(
qualifiedThirds: TeamStanding[],
source: ThirdPlaceSource
) {
const group = source.replace("3", "") as GroupId;
return qualifiedThirds.find(team => team.group === group);
}
Then apply the mapping:
function resolveThirdPlaceSlots(
qualifiedThirds: TeamStanding[],
mapping: ThirdPlaceMapping
) {
return Object.entries(mapping).map(([slot, source]) => {
return {
slot,
source,
team: getThirdPlacedTeamFromGroup(qualifiedThirds, source),
};
});
}
And the full flow becomes:
const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);
const combinationKey = getThirdPlaceCombinationKey(qualifiedThirds);
const mapping = thirdPlaceSlotMap[combinationKey];
const resolvedSlots = resolveThirdPlaceSlots(qualifiedThirds, mapping);
At this point, the app can place the correct third-placed teams into the Round of 32.
What made this interesting
I usually prefer deriving things from rules instead of hardcoding large tables.
But this was a case where the table itself is part of the rule.
The bracket is not just:
sort teams → seed teams → generate matches
It is closer to:
sort teams → identify qualified groups → use official mapping → generate matches
That small difference changes the architecture.
The app needs both:
- normal ranking logic
- a predefined scenario table
That is what made this more interesting than a standard tournament bracket.
Why I did not want to hide all of this
From the user’s point of view, none of this should feel complicated.
They should be able to fill out groups, move into the knockout rounds, and understand what happened.
But from the developer’s point of view, the Round of 32 is doing quite a lot behind the scenes.
That also creates a UX question:
How much of this logic should be visible?
If you expose every rule, the page starts to feel like documentation.
If you hide everything, the bracket can feel random.
That balance was one of the harder parts of the project.
The working version
I used this logic in a small bracket predictor here:
The main goal was to make the new 48-team format easier to play with, especially the Round of 32.
Building it reminded me that some “simple” sports tools are not simple because the UI is complex.
They are complex because the real-world rules are strange.
And sometimes the cleanest code is not the cleverest algorithm.
Sometimes it is a boring lookup table that faithfully represents the rules.