Z-Order (Morton Code) Calculator: Turn 2D Points Into One Number

A two-dimensional point has two numbers, and most storage systems prefer one. Databases, file formats and spatial indexes all like a single sortable key, because a single key can be ordered, searched and ranged over with machinery built for one-dimensional data. The problem is that flattening two dimensions into one usually destroys locality: points that sit side by side on a map can end up far apart in the flattened order, which makes "find everything near here" an expensive question. The Z-order curve, named for the Z shape its path traces, is a classic answer to that problem. It converts a pair of coordinates into a single integer, called a Morton code, by interleaving their bits, and points that are close together in space tend to receive codes that are close together numerically. The Z-Order (Morton Code) Calculator performs that interleaving, but the idea is easiest to trust once you have done it by hand.

Bit interleaving sounds technical and is actually simple. Write each coordinate in binary, then weave the bits together like a zip, alternating between the two numbers. The convention used here puts the bits of X in the even positions of the result and the bits of Y in the odd positions, counting from the least significant bit. That convention choice matters: swapping X and Y gives a different code for the same point, so any two systems that exchange Morton codes must agree on which coordinate goes in which position, and on how many bits each coordinate uses. Padding matters too. Coordinates must be written with the same number of bits before interleaving, because a missing leading zero shifts every bit that follows it. Once the convention and the bit width are fixed, the mapping is exact and reversible: given a Morton code, you can pull the bits apart again and recover the original coordinates.

How the tool works

The calculator takes a pair of non-negative integer coordinates and returns the Morton code produced by interleaving their bits. It works on integers because bit interleaving is defined on binary representations, and fractional or negative coordinates need a prior step, such as scaling or offsetting, before they can be encoded. The tool does that one job: it does not choose a bit width for you silently, and it does not pretend that a Morton code is a distance. Two points can have codes that are numerically close without being spatially close, and two points can be spatial neighbours with codes that are far apart, particularly at the boundaries between large Z-shaped blocks. Z-order preserves locality as a tendency, not as a guarantee, and any system built on it has to handle the boundary cases rather than assume them away.

It helps to see why the Z shape arises. Consider a small grid and order its cells by Morton code. The first four codes cover a two-by-two block in the corner, traced in a Z: top-left, top-right, bottom-left, bottom-right, depending on the axis convention. The next codes cover the neighbouring two-by-two block, and so on, with larger blocks built from smaller ones in the same pattern. That recursive block structure is why nearby points usually share a long prefix of their code: they sit in the same small block, which sits in the same larger block, and so on up the hierarchy. It is also why the ordering is useful for databases. A query for a rectangular region can be translated into a set of code ranges, one per block the region touches, and each range is a fast one-dimensional lookup even though the region itself is two-dimensional.

A worked example

Take the point (2, 3) and interleave its bits using the convention stated above: X bits in even positions, Y bits in odd positions, counting from the least significant bit. Write X = 2 in binary as 10, so its bits are x0 = 0 and x1 = 1. Write Y = 3 in binary as 11, so y0 = 1 and y1 = 1. Now place them: bit 0 of the result is x0 = 0, bit 1 is y0 = 1, bit 2 is x1 = 1, and bit 3 is y1 = 1. Reading the result from the most significant bit down gives 1110 in binary, which is 8 + 4 + 2 + 0 = 14 in decimal. So the Morton code of (2, 3) under this convention is 14. You can verify the decoding by reversing the process: the even-position bits of 14, which is 1110, are 0 and 1, giving X = 10 in binary = 2, and the odd-position bits are 1 and 1, giving Y = 11 in binary = 3. The round trip returns exactly the point you started with.

A second example confirms the pattern. Take (1, 2). X = 1 is 01 in binary, so x0 = 1 and x1 = 0. Y = 2 is 10 in binary, so y0 = 0 and y1 = 1. Interleaving gives bit 0 = x0 = 1, bit 1 = y0 = 0, bit 2 = x1 = 0, and bit 3 = y1 = 1, which reads as 1001 in binary, or 8 + 0 + 0 + 1 = 9. So (1, 2) encodes to 9. A third, minimal example: (0, 1) has X = 00 and Y = 01, so only bit 1 is set, giving binary 0010, which is 2. And (1, 0) gives only bit 0 set, which is 1. These tiny cases are the fastest way to check a convention: if your tool says (1, 0) encodes to 2 and (0, 1) to 1, it is using the opposite convention, with Y in the even positions, and you should not mix its codes with codes from a tool using the convention in this guide.

Common mistakes

The most common mistake is mixing conventions: encoding with one tool and decoding with another that places X and Y in opposite positions. The codes look reasonable and the decoded points look plausible, but every point comes back with its coordinates swapped. The second mistake is forgetting to pad coordinates to the same bit width, which shifts bits and produces codes that decode to different points entirely. The third mistake is feeding in negative or fractional coordinates without transforming them first; bit interleaving has no meaning for a minus sign or a decimal point, so the coordinates must be shifted into non-negative integers, and scaled if they are fractional, before encoding. The fourth mistake is over-claiming locality. Morton codes make nearby points usually close in code order, but a query that assumes a single contiguous code range covers a rectangle will miss points at block boundaries. Real systems decompose a rectangle into several ranges, and skipping that step produces silently incomplete results.

Honest limitations

A Morton code calculator encodes one point at a time. It does not build a spatial index, answer nearest-neighbour queries, or choose a bit width for a dataset. It does not handle three dimensions, where the same idea extends to interleaving three coordinates but needs a different tool, and it does not handle floating-point coordinates directly. It also does not make a bad spatial design good: if your data is clustered in one corner of the space, Z-ordering will not spread it out, and if your queries are mostly exact-point lookups rather than region queries, a plain two-column index may serve you better with less complexity. Morton codes are a tool for range-shaped problems, not a universal replacement for spatial indexing.

Closing

Bit interleaving is a small idea with a large payoff: two numbers become one, locality mostly survives, and a one-dimensional index can start answering two-dimensional questions. Do it by hand once, fix your convention in writing, and the calculator becomes trustworthy rather than mysterious. For neighbouring jobs, the Geohash Encoder and Decoder offers a different spatial encoding built on the same locality idea, and the Coordinate Format Converter handles coordinate notation before encoding, while How to Choose the Right Chart for Your Data helps when the next step is plotting the points you have encoded rather than indexing them.