GeoTIFF Tile Size & Pyramid Calculator

How to Calculate GeoTIFF Tile Grid Dimensions

The tile grid is simply the raster pixel dimensions divided by the tile size, rounded up. A 10,000 × 8,000 px raster with 256×256 tiles requires 40 × 32 = 1,280 tiles at full resolution. Switching to 512×512 tiles reduces this to 20 × 16 = 320 tiles — four times fewer, but each tile covers four times the area.

The tile count directly affects initial rendering speed. When a web map client loads a viewport, it requests every tile overlapping that viewport at the current zoom level. Fewer, larger tiles means fewer HTTP requests for large overviews; more, smaller tiles gives finer granularity for partial reads.

In GDAL, tiling is applied with:

Understanding GDAL Overview Pyramids

GDAL computes overview level count as:

For a 10,000 × 8,000 raster with 256×256 tiles: floor(log2(8000 / 256)) = floor(3.97) = 3 overview levels (2×, 4×, 8×), plus the full-resolution base — four levels total.

Build overviews in GDAL with:

The -r average resampling method produces the best visual quality for continuous data. Use -r nearest for categorical data (land cover, classification rasters) to avoid value blending.

Tiled GeoTIFF vs. MBTiles vs. XYZ: Which Format Should You Use?

Tiled GeoTIFF / COG is the best choice for GIS processing workflows. It preserves the full coordinate reference system, band metadata, and nodata values. A Cloud-Optimised GeoTIFF adds an internal layout that allows HTTP range requests, making it suitable for cloud object storage without a tile server.

MBTiles packages tiles into a single SQLite database. It is the dominant format for offline mobile maps (Mapbox, MapLibre) and desktop GIS applications that need a portable single-file delivery mechanism. MBTiles performs well up to roughly 5 billion pixels; above that, SQLite page management can become a bottleneck.

XYZ tiles store each tile as an individual file in a z/x/y.png directory structure. This is the simplest format to serve with any static web server and is compatible with all web mapping libraries (Leaflet, OpenLayers, MapboxGL).

Compression for Raster Tiles: LZW, DEFLATE, JPEG, ZSTD Compared

LZW is the safe default for any lossless GeoTIFF. It works across all GDAL versions, handles 8/16/32-bit data, and typically achieves 2–3× compression on imagery. Use it when compatibility matters more than maximum compression.

DEFLATE outperforms LZW slightly (2.5–4×) and is the recommended default for Cloud-Optimised GeoTIFFs. Combine with predictor=2 (horizontal differencing) for integer data or predictor=3 for float data to increase ratios further.

ZSTD (available in GDAL 3.1+) offers the best ratio for lossless compression (3–5× on 8-bit imagery) with faster decode speeds than DEFLATE. It is the recommended choice for large COGs on modern infrastructure.

JPEG achieves the highest compression (8–12×) but is lossy and limited to 8-bit RGB data. Never use JPEG for DEMs, classification rasters, or any single-band scientific data where pixel values must be exact.

Cloud-Optimised GeoTIFF (COG): Serving Rasters from Object Storage

A COG is a regular GeoTIFF with two structural properties: internal tiling and a specific byte ordering that places overview tiles before the full-resolution data. This layout allows HTTP clients to use range requests to fetch only the bytes covering a viewport window, without downloading the entire file.

COGs are served directly from S3, Google Cloud Storage, or Azure Blob without a tile server, reducing infrastructure cost. Libraries like rio-cogeo, gdal_translate, and QGIS's COG export can create them.

The recommended GDAL creation pipeline:

Why the ~33% Pyramid Overhead Rule Holds

Each overview level contains 1/4 the pixels of the previous level (half the width and half the height). Starting from the full-resolution base storage B, the series of overview sizes is:

B/4 + B/16 + B/64 + … = B × (1/4) / (1 − 1/4) = B/3

This geometric series converges to exactly 1/3 of the base storage — approximately 33% overhead — regardless of how many levels are built, for large enough rasters. Small rasters deviate from this rule because integer rounding means overview levels don't perfectly halve.

This means building a full overview pyramid almost always costs less than 35% extra disk space, while typically delivering 3–10× faster rendering at overview zoom levels. The trade-off is almost always worth it for any raster larger than a few thousand pixels per side.