A Cloud-Optimized GeoTIFF (COG) is a regular GeoTIFF raster organized internally so that clients can read just the portion they need over HTTP, using byte-range requests, instead of downloading the whole file. It is a valid GeoTIFF — any GDAL-based tool reads it — but its internal layout is optimized for cloud storage and streaming.
What makes a GeoTIFF "cloud-optimized"
Two structural features: internal tiling (the image is stored as a grid of blocks, commonly 512×512, rather than scanline strips) and internal overviews (precomputed reduced-resolution pyramids). A clear, ordered IFD layout lets a reader fetch the header once, then request only the tiles and overview level covering the current map view and zoom.
Why it matters
COGs let you host terabyte-scale imagery and DEMs on plain object storage (S3, GCS, Azure Blob) and serve them directly to web maps, QGIS, or analysis pipelines without a tile server or database. This is the backbone of modern STAC catalogs and on-demand earth-observation workflows — you read pixels where and when you need them.
Concrete example
Create one with GDAL's dedicated driver:
gdal_translate in.tif out_cog.tif -of COG -co COMPRESS=DEFLATE -co BLOCKSIZE=512
Validate the structure with the rio cogeo validate tool (rio-cogeo) or gdalinfo, which should report a block size and the presence of overviews. Serving is as simple as aws s3 cp out_cog.tif s3://bucket/.
Common pitfall
Renaming a .tif to imply it is a COG does nothing — the optimization is in the byte layout. An untiled, overview-free GeoTIFF on S3 forces clients to download the entire file. Always regenerate with the COG driver and validate. Also ensure your server and CDN honor HTTP range requests, or streaming silently degrades to full downloads.