What is Cloud Optimized GeoTIFF (COG)? Why It Matters for Web Mapping

A Cloud Optimized GeoTIFF (COG) is a standard GeoTIFF file that has been internally organised with tiled storage and pre-built overviews so that web applications can read just the portion of the image they need using HTTP range requests, rather than downloading the entire file. It is the same format, the same file extension, and carries the same geospatial metadata as any other GeoTIFF — the difference is entirely in how the bytes are arranged on disk.

If you have ever waited forty-five seconds for a 3 GB orthomosaic to download before you could see a single pixel, COG is the solution. I have spent years watching surveyors produce stunning raster deliverables and then struggle to share them because the files are simply too large for conventional web delivery. COG changes that equation entirely.

How a regular GeoTIFF stores data

To understand why COG matters, you need to understand how a traditional GeoTIFF is structured.

A standard GeoTIFF stores pixel data in strips — horizontal bands of image rows written sequentially. When a GIS application like QGIS opens the file, it reads the entire strip that contains the rows it needs to display. If you are zoomed into a small area in the bottom-right corner of the image, the application still needs to seek through the file from the beginning to find the relevant strips.

This works perfectly fine when the file is on your local hard drive. It is a disaster when the file is on a remote server, because every seek operation becomes a network request with latency.

Standard GeoTIFFs also lack pre-computed overviews. When you zoom out to see the entire dataset, the application must read every pixel and downsample on the fly — or the software builds an overview cache locally, which takes time and disk space.

What makes a GeoTIFF “Cloud Optimized”

A COG addresses both problems with two structural changes:

Internal tiling

Instead of strips, a COG stores pixels in square tiles — typically 256x256 or 512x512 pixels. Each tile is independently addressable within the file. When a viewer needs to display a specific geographic extent, it calculates which tiles overlap that extent and requests only those tiles via HTTP range requests.

This is the same principle behind web map tile services (WMTS), except the tiles live inside a single file rather than as thousands of individual PNG or JPEG files on a server.

Pre-built overviews (pyramids)

A COG contains multiple resolution levels embedded directly in the file. A full-resolution 20,000 x 20,000 pixel image might include overviews at 10,000 x 10,000, 5,000 x 5,000, 2,500 x 2,500, and so on. When the viewer is zoomed out, it requests tiles from the appropriate overview level — not the full-resolution data.

The overviews add roughly 30-40% to the file size, but they eliminate the need for the viewer to download and downsample the full dataset just to show a thumbnail.

COG vs regular GeoTIFF: comparison

The critical point: a COG is still a valid GeoTIFF. Every application that reads GeoTIFF can read a COG. The optimisation is additive, not a conversion to a different format.

How HTTP range requests make COGs work

HTTP range requests are the mechanism that makes COG practical. When a web browser (or any HTTP client) sends a request with a Range header, the server returns only the specified byte range from the file rather than the entire file.

Here is the sequence when a COG-aware viewer loads a map:

1. The viewer requests the first few kilobytes of the file to read the TIFF header and the Internal File Directory (IFD), which contains the byte offsets of every tile at every overview level.
2. The viewer calculates which tiles are needed for the current viewport and zoom level.
3. The viewer issues parallel HTTP range requests for just those tiles.
4. As tiles arrive, they are decoded and rendered on the map canvas.
5. When the user pans or zooms, the viewer requests the new tiles that come into view.

The total data transferred is typically a few megabytes even for a multi-gigabyte source file. The user sees the visible area almost immediately, and the rest of the file is never downloaded unless they navigate to it.

This works with any HTTP server or S3-compatible object storage that supports range requests — which includes AWS S3, Google Cloud Storage, Wasabi, and virtually every CDN.

How to create a Cloud Optimized GeoTIFF

Using GDAL (command line)

GDAL is the standard tool for geospatial raster operations. The gdal_translate command can convert any GeoTIFF to COG format:

gdal_translate input.tif output_cog.tif \
  -of COG \
  -co COMPRESS=DEFLATE \
  -co OVERVIEW_RESAMPLING=BILINEAR \
  -co TILING_SCHEME=GoogleMapsCompatible

Or, for a simpler conversion that preserves the original projection:

gdal_translate input.tif output_cog.tif \
  -of COG \
  -co COMPRESS=LZW \
  -co NUM_THREADS=ALL_CPUS

GDAL’s COG driver (available since GDAL 3.1) handles internal tiling and overview generation automatically. You do not need to run gdaladdo separately.

To verify your file is a valid COG, use the validation script:

python -m cogeo_mosaic.utils validate output_cog.tif

Or use rio cogeo validate from the rasterio library:

pip install rio-cogeo
rio cogeo validate output_cog.tif

Exporting from Pix4D

Pix4Dmapper and Pix4Dmatic can export orthomosaics as GeoTIFF. As of recent versions, you can enable COG output directly in the export settings:

1. Open Processing Options and navigate to the output section.
2. Under GeoTIFF export, select “Cloud Optimized GeoTIFF” if available.
3. If not available in your version, export as a standard GeoTIFF and convert with GDAL.

Exporting from Agisoft Metashape

Metashape exports orthomosaics and DEMs as GeoTIFF. To get a COG:

1. Export your orthomosaic via File > Export > Export Orthomosaic.
2. In the export dialog, select TIFF/GeoTIFF as the format.
3. Enable “Generate BigTIFF” for files over 4 GB.
4. After export, convert to COG using the GDAL command above.

Metashape does not natively produce COG-structured files, so the GDAL conversion step is currently required.

Exporting from DroneDeploy, WebODM, and others

Most photogrammetry platforms export standard GeoTIFFs. The GDAL conversion step is universal — it works regardless of the source application.

How COGs work in web viewers

Leaflet with georaster-layer-for-leaflet

The most common open-source approach for displaying COGs in a web map uses Leaflet with the georaster-layer-for-leaflet library:

import { parseGeoraster } from 'georaster';
import GeoRasterLayer from 'georaster-layer-for-leaflet';

const response = await fetch(cogUrl, {
  headers: { Range: 'bytes=0-65535' }
});
const georaster = await parseGeoraster(cogUrl);
const layer = new GeoRasterLayer({
  georaster,
  resolution: 256
});
layer.addTo(map);

The library handles range request logic internally, fetching tiles as the user pans and zooms.

MapLibre with COG protocol

MapLibre GL JS can display COGs using community protocol handlers that translate the tiled COG structure into MapLibre’s expected raster tile format. This gives you GPU-accelerated rendering with smooth zooming.

Titiler and dynamic tiling

For production deployments serving many COGs, Titiler (a FastAPI-based dynamic tile server) reads COGs from cloud storage and serves standard XYZ map tiles on the fly. This approach gives you the storage efficiency of COG with the compatibility of traditional tile services.

File size impact

A common concern is that COG files are larger than standard GeoTIFFs because of the embedded overviews. Here is a realistic comparison for a typical drone survey orthomosaic:

The 30% size increase is more than justified by the dramatic reduction in data transfer for web viewing. Your storage costs go up marginally, but your user experience improves by orders of magnitude.

When COG is not the right choice

COG is excellent for raster data that needs to be viewed in a web browser. It is not a universal solution:

• Vector data: COG is a raster format. For vector deliverables (contour lines, building footprints, survey boundaries), formats like GeoJSON, FlatGeobuf, or GeoPackage are more appropriate.
• Point clouds: For LiDAR or photogrammetric point clouds, formats like LAS/LAZ or COPC (Cloud Optimized Point Cloud) serve the same role that COG serves for rasters.
• 3D models: For textured meshes and 3D scene data, 3D Tiles or glTF are the relevant formats.
• Tiny files: If your GeoTIFF is under 50 MB, the overhead of COG optimisation provides minimal benefit — the file loads quickly regardless.

COG and Swyvl

When you upload a GeoTIFF to Swyvl, the platform automatically converts it to Cloud Optimized format during processing. Your orthomosaics, digital terrain models, and other raster layers are served as COGs through Leaflet-based viewers, so your clients see the data almost instantly without downloading multi-gigabyte files.

This is particularly valuable for sharing GeoTIFFs online with construction clients and project managers who do not have GIS software installed. They click your share link, see the orthomosaic on a map, and can pan and zoom with the same responsiveness they expect from Google Maps.

The future of cloud-native geospatial

COG is part of a broader shift toward cloud-native geospatial formats — file formats designed from the ground up (or retrofitted, in COG’s case) for efficient access over HTTP. Other formats in this family include:

• COPC (Cloud Optimized Point Cloud): the COG equivalent for LAS point cloud data
• FlatGeobuf: a cloud-friendly binary format for vector features
• GeoParquet: columnar storage for large vector datasets
• PMTiles: a single-file archive for map tile pyramids

The common thread is the same: structure the data so that clients can request exactly what they need via HTTP range requests, eliminating the need to download entire datasets before viewing them.

For surveyors and drone operators producing raster deliverables, COG is already the practical standard. If you are producing GeoTIFFs today, converting them to COG before delivery is one of the simplest, highest-impact improvements you can make to your workflow.