Menu

Method

Calculation Methodology

The 8:1 horizontal ratio

Overworld and Nether horizontal coordinates are proportional at 8 to 1. The ratio applies to X and Z only. Y is a reference height and is never scaled.

Overworld to Nether: XN = floor(XO / 8), ZN = floor(ZO / 8), YN = YO

Nether to Overworld: XO = 8 × XN, ZO = 8 × ZN, YO = YN

Floor versus truncation

Conversion uses floor toward negative infinity, matching Minecraft block behavior. A negative fraction such as -0.1 belongs to block -1, not 0. For example, -9 / 8 is -1.125 and floors to -2. The calculator never uses JavaScript parseInt or truncation toward zero, which would shift negative targets by one block.

Worked cases

SourceTarget
Overworld (800, 64, -400)Nether (100, 64, -50)
Overworld (-9, 70, 9)Nether (-2, 70, 1)
Overworld (-1, 64, -1)Nether (-1, 64, -1)
Overworld (7, 64, 7)Nether (0, 64, 0)
Overworld (-8, 64, -8)Nether (-1, 64, -1)
Overworld (-0.1, 64, 7.9)Nether (-1, 64, 0)
Nether (-2, 70, 1)Overworld (-16, 70, 8)
Nether (100, 64, -50)Overworld (800, 64, -400)

Round trips are intentionally lossy. Overworld X 7 becomes Nether X 0, and 0 becomes Overworld 0, not 7. This is expected floor behavior and is not treated as a bug.

Input precision and limits

X and Z may be positive, zero, or negative, including decimals. Decimal positions are floored to the block you are in before conversion. X and Z are limited to the documented world border range (about +/- 29,999,984 Overworld and +/- 3,749,998 Nether). Values beyond that, unsafe integers, and non-finite numbers are rejected. Y is limited to -2048 to 2048 as a reference height and is not scaled.

Empty X or Z is an error. Empty Y means unknown and is carried as unknown, never as zero. The result is disabled while any field is invalid.

Edition differences

The X and Z conversion is identical in Java and Bedrock. Only the documented portal search behavior differs. In Java Edition, when the destination is the Overworld, the candidate area is roughly ±128 blocks on each horizontal axis (about 256 blocks across, or 257 inclusive block columns); when the destination is the Nether, it is roughly ±16 (about 32 across). In Bedrock Edition it is roughly ±128 in either destination dimension. These are lookup areas with 3D distance checks, not a guaranteed link radius.

Portal link checker model

The Nether Portal Link Checker reuses this converter, then tests only the active destination portals a visitor enters. Eligibility is an axis-aligned square in X/Z, not a circular radius, and Y does not remove a candidate. Eligible candidates are ranked by full 3D Euclidean distance from the converted target, so height can change the winner.

Each portal is treated as one representative reference point rather than the whole frame or the exact player entry block. The return trip is calculated separately from the likely arrival portal's own point, because the game does not store a permanent reciprocal pair. Boundary points, exact ties, and missing Y are reported as uncertain or insufficient rather than being resolved with invented precision.

Portal frame dimensions and obsidian counts

The Nether Portal Size Calculator uses outer frame width W and height H from 4–23 and 5–23. The opening is (W−2) by (H−2), and the obsidian count is 2W + 2H − 4 with all four corners or 2W + 2H − 8 without them. Opening mode accepts the clear interior and adds the two edge blocks on each axis before applying the same formula.

The blueprint generates exactly W×H cells: perimeter cells are obsidian, interior cells are the opening, and corners are either obsidian or explicitly omitted. Automated tests check all 380 valid outer combinations against their grid-cell counts. The optional budget planner enumerates the same 380 frames and ranks fits by opening area, required obsidian, squareness, then width and height. Counts assume one isolated standalone frame, not shared edges across a multi-portal build.

Nether highway distance and materials model

The Nether Highway Calculator reuses the same floor conversion for two Overworld stops. It reports straight-line distance ashypot(dx, dz) and the buildable X/Z distance as |dx| + |dz|. Both use whole-block Nether endpoints; Y is reference-only and never changes horizontal distance.

Corridor material counts use inclusive integer rectangles for each nonzero axis leg and subtract their bend intersection, so the result is an O(1) geometric count rather than a block-by-block simulation. The page supports a full-width floor or a single center lane, with the remaining floor cells counted separately. It assumes one isolated corridor and does not estimate terrain clearing, walls, roof, lighting, supports, or portal obsidian.

Travel times divide the selected geometric distance by cited nominal walking, sprinting, packed-ice boat, or blue-ice boat speeds. Ice-boat figures are theoretical top speeds, and portal transit, acceleration, turns, and obstacles are excluded.

Guide example derivation

The How to Link Nether Portals guide derives its worked coordinates through this same converter rather than a separate formula. Its negative example shows the expected lossy round trip: Overworld X -9 floors to Nether X -2, and the ideal reverse conversion is Overworld X -16, not the original -9. That asymmetry is arithmetic; it is not evidence by itself that a real portal link is broken. Deterministic tests check the guide examples against independent expected values.

The Nether portals not linking troubleshooting guide reuses the same converter and 3D distance function for its worked scenarios. It distinguishes a wrong existing candidate from a missing one, treats outbound and return searches separately, and labels generated portal placement as terrain-dependent rather than formula-predictable. Its diagrams are schematic examples of the site's model, not screenshots or verified game outcomes.

What the calculator cannot know

The tool cannot see existing portals, terrain, or the game's actual candidate selection. A result is an ideal plotting target. A generated portal may appear at a different position and height, and an existing nearby portal may take priority.

Testing and maintenance

The calculation, parsing, validation, and share-state modules are covered by automated unit tests, including all named worked cases above, negative and fractional inputs, unknown Y, malformed input, and overflow. The link checker adds tests for edition eligibility, the square search area, 3D ranking, boundary approximations, exact ties, deactivated portals, independent return trips, one-way mismatches, and share-token validation. The size calculator adds tests for all 380 valid outer frames, blueprint cell counts, corner toggles, opening conversion, stack formatting, SVG export markup, budget ranking, and frame URL state. The highway planner adds tests for two-point conversion, cardinal directions, route-order bends, rectangle-union material counts, large-coordinate arithmetic, and share-state validation. These tests prove the model's code behavior. They do not prove every game engine edge case, portal selection result, or terrain outcome.

These mechanics have not been re-tested inside a running Java or Bedrock world for this build. Where game behavior is described, it is based on the community-maintained Minecraft Wiki and should be verified for the specific version you play.

Sources