DEV Community

Mark
Mark

Posted on

Encoding FIFA’s 495 third-place scenarios for the 2026 World Cup

#algorithms #computerscience #programming #showdev

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;
};
Enter fullscreen mode Exit fullscreen mode

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
  );
}
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

Then you take the top 8:

const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);
Enter fullscreen mode Exit fullscreen mode

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"]
Enter fullscreen mode Exit fullscreen mode

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"]
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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("");
}
Enter fullscreen mode Exit fullscreen mode

So if the qualified third-placed teams came from groups C, D, E, F, G, I, K, and L, the key becomes:

"CDEFGIKL"
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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
};
Enter fullscreen mode Exit fullscreen mode

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);
}
Enter fullscreen mode Exit fullscreen mode

Then apply the mapping:

function resolveThirdPlaceSlots(
  qualifiedThirds: TeamStanding[],
  mapping: ThirdPlaceMapping
) {
  return Object.entries(mapping).map(([slot, source]) => {
    return {
      slot,
      source,
      team: getThirdPlacedTeamFromGroup(qualifiedThirds, source),
    };
  });
}
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

It is closer to:

sort teams → identify qualified groups → use official mapping → generate matches
Enter fullscreen mode Exit fullscreen mode

That small difference changes the architecture.

The app needs both:

  1. normal ranking logic
  2. 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:

https://bracket2026.com

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.

References

Top comments (0)