Quadkey to Tile XYZ Converter

This converter decodes that sequence into the familiar X column, Y row, and zoom level used by slippy map tile systems. It is useful when moving tile references between Bing Maps conventions and XYZ URLs, inspecting cached map data, or checking an implementation against a known result. The calculation is deterministic and local: it reads each digit once, performs integer arithmetic, and never contacts a map provider. Valid keys contain only digits zero through three, and their length directly determines the returned zoom level.

How quadkey digits encode an XYZ tile

A Bing Maps quadkey describes a route through a tiled map pyramid. Every zoom step divides the current square into four quadrants, and one digit records which child square contains the target tile. Digit zero selects the upper-left child, digit one selects the upper-right child, digit two selects the lower-left child, and digit three selects the lower-right child. Those choices correspond to one binary bit for X and one binary bit for Y. Zero contributes no bits, one contributes an X bit, two contributes a Y bit, and three contributes both. The decoder reads from left to right because the earliest digit is the most significant decision in the path. At each step it doubles the accumulated X and Y values, then adds the bits represented by the current digit. After the final digit, the two accumulators are the tile column and tile row. The number of processed digits is the zoom level. For example, a four-character quadkey always identifies a tile at zoom four, where both coordinates fall between zero and fifteen. This direct relationship makes decoding exact: it requires no geographic projection, latitude, longitude, rounding rule, external map service, or provider-specific lookup table. The returned values can therefore be inserted directly into a standard zoom/X/Y tile path when the source and destination use the same Web Mercator tile orientation.

Preparing input and interpreting the result

Provide one quadkey as a string under the quadkey field. Leading and trailing whitespace is removed so that a value copied from a text file does not fail merely because it includes an accidental space or line ending. The cleaned value must still contain at least one character, and every character must be one of zero, one, two, or three. Internal spaces, punctuation, negative signs, decimal notation, and other digits are rejected because they do not represent valid quadrant choices. This capability accepts up to thirty digits, which covers normal web mapping zoom levels while keeping all returned integers exactly representable and easy to exchange as JSON. A successful response contains the normalized quadkey, X, Y, and zoom. X is the horizontal tile index increasing from left to right, while Y is the vertical tile index increasing from top to bottom in the usual slippy map convention. Zoom is simply the quadkey length, not a value inferred from either coordinate. Preserve all leading zero digits when sending a key: they may not change the numeric X or Y value at that stage, but they do change the zoom and therefore identify a different tile. API use costs $0.002 per item. Because the browser and API call the same pure solver, a key tested interactively will decode the same way in an automated migration or validation job.

Using decoded coordinates safely in map workflows

Decoded tile coordinates are most helpful when a system stores Bing-style identifiers but another component expects XYZ paths. A migration script can decode each database key, then construct a path such as zoom/X/Y for a compatible tile cache. An engineer investigating a failed image request can extract its quadkey and compare the resulting coordinates with logs from an XYZ server. Test suites can also keep a small set of known keys and assert their decoded results after refactoring map code. Remember that this conversion identifies a tile, not a point inside it. It does not return geographic bounds, a center latitude and longitude, pixels, meters, or an image. Those follow-up values require additional Web Mercator calculations and assumptions about tile size. Also verify the Y-axis convention of the destination system. Standard XYZ and Bing tile coordinates count Y downward from the north, but TMS-style storage often flips Y at a given zoom; this decoder intentionally returns the unflipped Bing and XYZ row. Treat quadkeys as strings rather than numbers, since numeric storage removes meaningful leading zeros and can alter the zoom. For large imports, validate bad records separately instead of silently skipping characters, because changing or removing one digit selects a different branch of the pyramid. The deterministic response makes these checks reproducible across browsers, workers, command-line tools, and continuous integration environments without network availability.