Nether Portal Link Checker

1. Choose Java or Bedrock. This changes the approximate search area, not the 8:1 math.
2. Add every relevant active portal you have entered, with its dimension and full X, Y, and Z portal-block reference point.
3. Pick the portal you will enter and the portal you want to exit at.
4. Read the converted target, the candidate table, the likely winner, and the separate return trip.
5. Verify the real destination in game before moving anything valuable.

If you only need one portal's coordinate conversion, use the homepage Nether portal coordinate calculator. This checker is for comparing several existing portals and diagnosing a conflict.

When you enter a portal, the game converts your entry position into the other dimension. X and Z are scaled by 8 and floored toward negative infinity. Y is not scaled; it stays a height reference.

The game then searches for existing portal points of interest inside a horizontal, axis-aligned candidate area around the converted target. That area covers the available height, so Y does not remove a candidate. Among eligible candidates, the closest portal point in full 3D distance wins, including Y.

If no existing portal qualifies, the game may generate a new one. This checker does not model terrain, generation, or unentered portals, so it reports "no eligible entered candidate" instead of inventing a generated portal coordinate.

These are approximate planning ranges. They describe where the game looks, not a guaranteed link radius. Version, chunk edges, and the exact portal point-of-interest can change boundary behavior.

The coordinate conversion is identical in both editions. The edition selector changes only candidate eligibility, never the 8:1 ratio.

Candidate search areas can overlap. Two Overworld portals that are close together may convert to targets inside the same Nether area, so both trips can choose the same Nether portal.

Height can also break a horizontal tie. In a tested model case, an Overworld source at(0, 64, 0) converts to a Nether target at (0, 64, 0). A Nether portal at(1, 200, 0) is only 1 block away horizontally, but its 3D distance is about 136. A portal at (5, 64, 0) is 5 blocks away horizontally and wins at 3D distance 5. Horizontal eligibility is not the same as the final ranking.

A trip is not a permanently remembered portal pair. On the way back, the game starts from the portal block you actually enter, converts that position, and runs a fresh candidate search in the reverse dimension.

In the worked example below, entering from Home sends the trip to Blaze farm. Starting the return from Blaze farm converts back to (816, 64, -400), where Village is 8 blocks away and Home is 16. The return therefore points to Village, not Home. This is a one-way mismatch, and the checker shows it explicitly instead of assuming reciprocity.

This is the same deterministic example network used by the automated tests. The interactive tool preloads its Home and Base portals so you can start checking immediately. It is fictional data, not a real world save.

• Home — Overworld (800, 64, -400), the source.
• Village — Overworld (808, 64, -400).
• Base — Nether (100, 70, -50), the intended destination.
• Blaze farm — Nether (102, 64, -50).

Java mode converts Home to the Nether target(100, 64, -50) and searches about ±16 X/Z. Both Nether portals are eligible.

Base shares the target's X and Z but sits 6 blocks higher, so its 3D distance is 6. Blaze farm is 2 blocks east at the same height, so its 3D distance is 2. The prediction isanother entered portal likely wins, not the intended Base.

The reverse trip from Blaze farm points to Village, while Home is farther away. If Blaze farm is deactivated, Base becomes the outbound winner at distance6, and the return search points back to Home among the entered records. Deactivating a portal is a real change to your world, so verify what uses it first.

• Bring the converted X/Z targets closer to the portal you want the trip to use.
• Reduce the Y difference if two eligible portals compete for the same target.
• Check the return trip separately before assuming the pair is stable.
• Record the real arrival portal block in game, then re-enter that exact point in the checker.
• Deactivating an unused competing portal can change a result, but it is a destructive in-game action. Confirm what depends on that portal first.

No layout is guaranteed to force a link. If a result still seems wrong in your world, the dedicated Nether portal troubleshooting guide explains wrong exits, shared destinations, generated portals and one-way returns in more detail.

Need the intended pair built from scratch? Follow the two-way portal linking steps.

The checker reuses the homepage converter: source X and Z are floored to block coordinates, divided by 8 when entering the Nether, or multiplied by 8 when entering the Overworld. Y is copied and never scaled. It then tests entered active destination portals with an axis-aligned square, not a circular radius, and ranks eligible candidates by full 3D Euclidean distance.

Each portal is treated as one representative reference point. The real frame can occupy several blocks, the player entry point can differ, and the game's point-of-interest selection is more detailed than this model. That is why the page says "likely" and marks boundary or tie cases as uncertain.

The return trip is a separate prediction that starts from the likely arrival portal's reference point. The checker never assumes the forward pair is reciprocal.

Automated unit tests cover the 8:1 conversion, negative flooring, edition eligibility, the square search area, Y-aware ranking, deactivated portals, ties, missing Y, share-state validation, and the one-way return mismatch. Passing these tests proves the model's code behavior, not a verified result in every Minecraft version or world.

Read the full calculation methodology for the converter's input rules and limits.

Sources

• Minecraft Wiki: Nether Portal— Frame dimensions, obsidian counts, and the 8:1 dimensional ratio.
• Minecraft Wiki: Nether portals tutorial— Portal linking behavior, candidate search areas, and edition differences.
• Minecraft Wiki: Nether survival tutorial— Portal construction examples, minimum frame, and ruined-portal repair.
• Minecraft Wiki: Crying obsidian— Crying obsidian cannot replace the functional frame edges.
• Minecraft Wiki: Ruined portal— Ruined structures may contain crying obsidian and need repair before use.
• Minecraft Wiki: Point of Interest— Portal blocks as points of interest used by the game search.
• Minecraft Wiki: Nether hub tutorial— Converting endpoints and building routes between Nether portals.
• Minecraft Wiki: Player movement— Nominal walking and sprinting movement speeds.
• Minecraft Wiki: Blue Ice— Blue-ice boat transport reference and top-speed context.
• Minecraft Wiki: Transportation methods— Packed-ice and blue-ice boat transport comparisons.

Minecraft Wiki is a community-maintained reference, not official Mojang documentation. This page has not been independently re-tested inside every Java or Bedrock version.

Need just one conversion? Convert a single portal's Overworld and Nether coordinates on the homepage calculator. It shows the floor formula, negative-coordinate handling, and copyable target X/Z without a portal network.

Building or resizing the frame itself? Plan a valid portal frame with the size calculator, including the opening, obsidian count, and corner options.

Connecting two bases? Plan a tunnel between two Overworld stops with converted Nether endpoints, X/Z directions, and a corridor material estimate.

Need to build the intended pair first? Learn how to link two Nether portals with a step-by-step workflow and a two-way verification checklist.