Slippy map tiles covering a bounding box

Provide west, south, east, north, and a zoom level, and the calculator returns every intersecting tile in deterministic row-major order. It also reports compact x and y ranges, whether the box crosses the antimeridian, and whether polar latitude had to be clamped to Web Mercator. This makes cache estimates, offline map downloads, render queues, and coverage checks reproducible without querying a tile provider.

Define the geographic area and zoom

Enter the bounding box as west, south, east, and north in WGS84 decimal degrees, then choose an integer zoom from 0 through 22. South must be below north, and west and east must differ. Most boxes have west less than east. When west is greater than east, the calculator deliberately interprets the area as crossing the antimeridian, so a region around Fiji or the Bering Strait does not accidentally expand across almost the entire planet. To request the whole longitudinal world, use -180 for west and 180 for east. The calculation uses the familiar XYZ slippy-map convention: x increases from west to east, y increases from north to south, and z is the selected zoom. Latitude beyond the Web Mercator limit is accepted as geographic input but projected to the nearest representable map edge. The result flags that clamp, helping you explain why polar geographic bounds cannot create additional rows beyond the top or bottom map tiles.

Understand which boundary tiles are included

The returned list contains tiles that overlap the bounding box with positive area. A tile touched only along the east or south boundary is not added, which prevents an exact tile-aligned box from receiving an unnecessary extra column or row. The west and north edges select the tiles immediately inside the area. This half-open edge treatment is especially useful for cache planning because adjacent bounding boxes can be processed without systematically inflating both sides of every shared boundary. Each tile is an object with x, y, and z, and tiles are ordered by y row from north to south. Within a row, x proceeds west to east; an antimeridian box finishes the western high-x segment before continuing at x zero. The response also includes x_ranges and y_range so callers can inspect or store the compact coverage without reconstructing it from the full list. Tile count is computed before allocation, and requests covering more than 100,000 coordinates are rejected with a clear input error.

Use the coordinates in a cache workflow

Treat the output as a deterministic plan, not as downloaded map content. The capability performs no network requests and has no knowledge of a provider, style, file extension, access token, or usage policy. Your application can map each XYZ object to a provider URL, a local directory such as z/x/y, a database key, or a rendering job. Check tile_count before scheduling work so storage, bandwidth, and provider quotas are explicit. For repeatable offline packages, save the input bounds and zoom alongside the coordinate list; another run with the same input produces the same ordering and values. If a region needs several zoom levels, call the capability once per zoom because each level has its own grid and rapidly increasing tile count. Large areas at high zoom should be divided geographically or planned at a lower level first. The API price is $0.002 per request, while any downstream tile hosting or retrieval charges remain entirely separate and depend on the provider you choose.