What is a GeoTIFF? Format, Tags, and COG

A GeoTIFF is a TIFF (Tagged Image File Format) image file that carries georeferencing metadata in standardized tags, so each pixel maps to a coordinate on Earth. The tags record the coordinate reference system (CRS), the pixel size, and the position of the grid origin. A Cloud Optimized GeoTIFF (COG) arranges the same file so clients can read parts of it over HTTP. This article's claim is that a GeoTIFF's internal layout, more than its size, sets how many bytes a reader must fetch to answer a question. It tests that claim on one real file, a Sentinel-2 image of Mount Rainier, from its header bytes to a SQL query.

Key takeaways

• GeoTIFF adds georeferencing tags to TIFF 6.0. Any TIFF reader opens the pixels, and geographic information system (GIS) software also places them on the map.
• The format began as a community specification in 1995. The Open Geospatial Consortium (OGC) adopted it as the OGC GeoTIFF Standard 1.1 in 2019.
• A Cloud Optimized GeoTIFF is tiled, carries overviews, and puts its header first, so a reader fetches only the bytes a question needs. The OGC standardized it in 2023.
• One real Sentinel-2 COG of Mount Rainier holds 164.3 MB. Its header fits in one 16 KB request, and a 1 km box at the summit takes 2.5 MB.
• WherobotsDB reads GeoTIFFs in place on S3 as out-db rasters and writes results back as COG.

What is a GeoTIFF?

GeoTIFF is the standard file format for raster geospatial data. It extends the Tagged Image File Format, which Aldus first published in 1986. The TIFF 6.0 specification of June 1992 defined tiled images and reduced-resolution subfiles, the two features every COG depends on. TIFF 6.0 also requires readers to skip unknown fields, so georeferencing could be added without breaking existing software.

GeoTIFF vs TIFF

	TIFF	GeoTIFF
Defined by	TIFF 6.0 (Aldus, 1992)	OGC GeoTIFF 1.1 (2019), on top of TIFF 6.0
Stores	Pixels, image size, compression, color model	All of TIFF, plus CRS, pixel size, and grid origin
Location of a pixel	Row and column only	A coordinate on Earth
Opens in	Any image reader	Any image reader; GIS software also places it on a map

How a GeoTIFF works

A GeoTIFF has three layers: the image data, the TIFF tags that describe it, and the geo tags that place it.

The georeferencing tags

Six TIFF tags carry the georeferencing, each with a fixed number in the OGC standard:

Tag	Number	What it holds
ModelPixelScaleTag	33550	The ground size of one pixel
ModelTiepointTag	33922	A pixel position tied to a ground coordinate
ModelTransformationTag	34264	A full affine matrix that replaces the two tags above when the grid is rotated
GeoKeyDirectoryTag	34735	Mandatory. The list of GeoKeys, small coded entries that name the CRS
GeoDoubleParamsTag	34736	GeoKey values that do not fit in a short integer
GeoAsciiParamsTag	34737	GeoKey values that do not fit in a short integer

The GeoKeys reuse EPSG codes, the standard numeric IDs for coordinate reference systems from the EPSG Geodetic Parameter Dataset. ProjectedCRSGeoKey (3072) holds a projected CRS, a flat map grid. An example is 32610: zone 10N of the Universal Transverse Mercator (UTM) grid on the World Geodetic System 1984 (WGS 84) model of Earth's shape. Its EPSG name is WGS 84 / UTM zone 10N. GeodeticCRSGeoKey (2048) holds a geographic CRS in longitude and latitude, such as 4326. The value 32767 marks a user-defined CRS. GTRasterTypeGeoKey (1025) records whether a coordinate marks a pixel corner (PixelIsArea) or a pixel center (PixelIsPoint). The GeoTIFF driver of GDAL, the open-source raster library, shifts PixelIsPoint files by half a pixel to line up the two conventions. GDAL RFC 33, a GDAL design proposal (request for comments), sets out the rule.

The Rainier file is a Sentinel-2 red band (B04) from July 8, 2025. Its header holds four values that place all 120.6 million pixels. They are a pixel scale of 10 by 10 m, a tie point from pixel (0, 0) to 499,980 E, 5,200,020 N, ProjectedCRSGeoKey 32610, and PixelIsArea.

Strips, tiles, compression, and overviews

Image data is stored in strips or tiles. A strip is a set of pixel rows written in sequence. A tile is a square block, typically 256, 512, or 1024 pixels wide. With tiles, a reader fetches one region without reading the rows above it. The Rainier band is cut into 121 tiles of 1024 by 1024 pixels.

Compression applies to each strip or tile on its own. LZW, the Lempel-Ziv-Welch method, and Deflate are lossless and widely supported: they keep every value exactly. ZSTD, the Zstandard method, and LERC (Limited Error Raster Compression) are faster or smaller and need newer readers. The Rainier file stores 16-bit integers with Deflate and a horizontal predictor. The predictor stores each pixel as its difference from the pixel before it, so the data compresses better.

Overviews are lower-resolution copies of the image stored inside the file, at 2x, 4x, 8x and so on. A viewer at continental zoom reads the smallest one. The Rainier band has four, down to 687 by 687 pixels.

A GeoTIFF can hold one band or many, in integer or floating point. A band is one layer of pixel values on the grid. A NoData value marks pixels with no measurement. Classic TIFF uses 32-bit offsets, which caps a file at 4 GB. BigTIFF switches to 64-bit offsets and lifts the limit.

Cloud Optimized GeoTIFF

A Cloud Optimized GeoTIFF is a GeoTIFF laid out for reading over HTTP. The OGC Cloud Optimized GeoTIFF Standard 1.0, approved in May 2023, sets these requirements:

• Every image is tiled, and tiles are square.
• Each overview is 2 to 10 times smaller than the one before.
• The smallest overview is one tile across or down.
• The server supports byte range requests, as defined in RFC 9110. A range request asks for one span of bytes from a file.

The specification recommends an order: header and image directories first, then overview tiles from smallest to largest, then the full-resolution tiles.

Feature	Plain GeoTIFF	Cloud Optimized GeoTIFF
Layout	Strips or tiles, any order	Square tiles, overviews, directories at the front
Read pattern	Download the whole file	One range request for the header, then the tiles needed
Standard	OGC GeoTIFF 1.1 (2019)	OGC COG 1.0 (2023), built on GeoTIFF 1.1
Validity	Valid TIFF	Also a valid GeoTIFF; any reader opens it

The GDAL COG driver, added in GDAL 3.1, writes the layout in one step, with 512-pixel tiles and LZW compression by default. The Rainier file uses 1024-pixel tiles at full resolution and follows the recommended order.

GeoTIFF examples

Much raster data in Earth observation is distributed as GeoTIFF:

• Satellite imagery. The U.S. Geological Survey (USGS) delivers Landsat Collection 2 as COGs, one per band. The Sentinel-2 COG archive on AWS, maintained by Element 84, converts every Sentinel-2 Level-2A band from JPEG 2000 to COG. Level-2A is the atmospherically corrected product. Each scene has STAC metadata, a standard JSON record of the scene and its files. The Rainier file comes from this archive.
• Elevation. A digital elevation model (DEM) is a grid of surface or ground heights. The Copernicus DEM on AWS serves GLO-30, the 30 m DEM, as one-degree COG tiles. The tile around Rainier, N46 W122, is 3,600 by 3,600 float32 pixels, tagged PixelIsPoint in EPSG:4326.
• Derived products. Analysts write NDVI (normalized difference vegetation index), classified land cover, and flood depth back to GeoTIFF for other tools to read.
• Weather and climate. Teams export model output as GeoTIFF for GIS users who do not read GRIB, a gridded binary file format, or NetCDF.
• Machine learning and web maps. Pipelines write prediction rasters as GeoTIFF, and tile servers serve map tiles from COGs in object storage with no conversion step.

How to open a GeoTIFF

QGIS, a free GeoTIFF viewer, and ArcGIS Pro place a dropped-in file on the map. On the command line, gdalinfo prints the CRS, bands, tiling, and overviews. In Python, rasterio reads the file. Google Earth Pro imports it as an image overlay. For data on S3, WherobotsDB opens the file in place and reads only the tiles a query covers.

GeoTIFF in Wherobots

WherobotsDB reads GeoTIFF as a native raster type and writes it back, including as COG.

RS_FromGeoTiff loads a file's bytes into an in-db raster stored in the table. RS_FromPath creates an out-db raster, a reference to the GeoTIFF in S3. It fetches a tile only when a function reads its pixels. For a COG, each fetch is a range request.

The Sentinel-2 L2A scene index in Wherobots Open Data links each scene to its band COGs. It points to the sentinel-cogs bucket that holds the Rainier file. The query below reads one file and one point:

Source	Format	Size	What the query read
Sentinel-2 L2A red band (B04), scene S2B_10TES_20250708_0_L2A, in the sentinel-cogs bucket on S3	Cloud Optimized GeoTIFF, unsigned 16-bit, Deflate	164.3 MB; 10,980 by 10,980 pixels in 121 tiles	The 16 KB header and the one 1.03 MB tile that holds the summit
Summit point	Longitude and latitude written in the SQL	One point	Transformed to EPSG:32610 to match the raster

The query opens the red band in place and reads its header and one pixel:

WITH r AS (
  SELECT RS_FromPath(
    's3://sentinel-cogs/sentinel-s2-l2a-cogs/10/T/ES/2025/7/S2B_10TES_20250708_0_L2A/B04.tif',
    'raster.reader.auto-rescale=false') AS rast
)
SELECT RS_Metadata(rast)        AS md,
       RS_BandPixelType(rast)   AS pixel_type,
       RS_BandNoDataValue(rast) AS nodata,
       RS_Value(rast, ST_Transform(ST_SetSRID(ST_Point(-121.7603, 46.8523), 4326),
                                   'EPSG:32610')) AS summit_dn
FROM r

RS_Metadata reports the fields the file header holds. They are an upper-left corner at 499,980 E, 5,200,020 N, a grid of 10,980 by 10,980 pixels, and a 10 m pixel in both directions. It also reports a spatial reference identifier (SRID) of 32610, one band, and 1024 by 1024 internal tiles. The band is unsigned 16-bit with NoData 0. The summit pixel stores the digital number (the raw integer) 4004, a reflectance of 0.4004 on snow and ice. The auto-rescale=false option keeps the raw value. The summit sits in tile (1, 9), so the read costs the 16 KB header plus one 1.03 MB tile.

Havasu is the Apache Iceberg table format extended with a native raster type. It stores millions of GeoTIFF references as rows with metadata columns. It also applies spatial filters during the scan, so a query for one county reads only the files that intersect it. Copernicus DEM GLO-30 is stored this way as raster tiles ready to query.

RS_ functions then run in parallel across every raster in the table: RS_Clip, RS_Resample, RS_Tile, and RS_ZonalStats. RS_AsGeoTiff serializes a raster to GeoTIFF bytes. RS_AsCOG writes a Cloud Optimized GeoTIFF with tiling and overviews. Results go to the customer's S3 bucket for any other tool to read. The STAC reader registers every GeoTIFF asset in a catalog as an out-db raster in one step.

WherobotsDB runs raster and vector data in one engine; most stacks pick one. A GeoTIFF can join to parcels or buildings in the same query that reads it. WherobotsDB is built by the original creators of Apache Sedona, 100% code compatible across all spatial functions.

A closer look at the Rainier COGs

A small reader that logs every HTTP range request opened five Sentinel-2 assets of scene S2B_10TES_20250708_0_L2A and the Copernicus DEM tile N46 W122. Each finding below comes from those logs.

The header always fit in one request. For all six files, the first 16 KB request returned every image directory and every tile offset. In the red band, image data starts at byte 3,562, so all directories and offsets fit in the first 3.6 KB of the 164.3 MB file.

Producers make different choices inside one standard. The Sentinel-2 bands switch to 512-pixel tiles in their overviews. The DEM uses 1024-pixel tiles at every level and the floating-point predictor. Only the DEM carries GDAL's ghost area, a text block after the TIFF signature that starts LAYOUT=IFDS_BEFORE_DATA and BLOCK_ORDER=ROW_MAJOR. The GDAL COG driver writes it so optimized readers can skip steps.

Scale and offset are stored outside the file, and the listed offset does not apply. The red band's GDAL metadata holds only the overview resampling method (AVERAGE). The STAC item lists scale 0.0001 and offset -0.1 in its raster:bands block. These files carry no +1000 digital-number offset. In the smallest overview of the same scene, the 1st percentile of the blue band is 166 and the minimum is 39. Reflectance here is the digital number times 0.0001. Applying the STAC offset as well gives reflectance that is too low and, for dark pixels such as water and shadow, negative.

The cost of a small question depends on tile size. The 1 km box at the summit is 101 by 101 pixels, about 20 KB of 16-bit values. The summit sits 28 pixels below a tile boundary, so the box falls across 2 of the red band's 121 tiles. The read cost 2.48 MB in 3 requests. In the 20 m scene classification layer, which uses 512-pixel tiles, the same box cost 54 KB. Larger tiles mean fewer requests for big windows, more bytes for small ones.

Previews from overviews are cheap. The smallest true-color overview, at 160 m, covers the whole 110 km tile in 739 KB and 5 requests, 0.3% of the 236.4 MB file.

GeoTIFF research

From a tag set to the OGC GeoTIFF and COG standards

Per the OGC standard's preface, SPOT Image proposed a GeoTIFF structure limited to UTM in September 1994. Niles Ritter of the Jet Propulsion Laboratory and Mike Ruth of SPOT Image formalized it as the GeoTIFF Format Specification, Revision 1.0 in November 1995. In The GeoTiff data interchange standard for raster geographic images (International Journal of Remote Sensing, 1997), Ritter and Ruth set out the design. Projection, datum, and pixel size are encoded as GeoKeys inside a single TIFF tag. The keys follow the geodetic model of the Petrotechnical Open Software Corporation (POSC). New keys could be defined without registering new TIFF tags.

The OGC adopted GeoTIFF 1.1 in September 2019 and changed little on purpose. Its submitters included IGN, the French national mapping agency, and the HDF Group. They also included the International Association of Oil & Gas Producers (IOGP), NASA, and the U.S. National Geospatial-Intelligence Agency (NGA). The revision aligned GeoKeys with the EPSG Geodetic Parameter Dataset as it now stands and kept every 1.0 file valid. NASA lists OGC GeoTIFF 1.1 as an approved Earth science data systems standard.

The cloud layout came from practice first. The conventions were settled on cogeo.org and implemented in GDAL. Frank Warmerdam describes the library's design in The Geospatial Data Abstraction Library (Open Source Approaches in Spatial Data Handling, 2008). UAB-CREAF, Planet, Spatialys, and Development Seed submitted the OGC COG standard. Its editors note in the preface that it follows the community's decisions and modifies neither TIFF nor HTTP. The standard also defines a media type, image/tiff; application=geotiff; profile=cloud-optimized, and the STAC item for the Rainier scene uses that exact string for each band.

Cloud-native repositories

COG belongs to a wider argument about where analysis runs. In Cloud-Native Repositories for Big Scientific Data (Computing in Science and Engineering, 2021), Abernathey and colleagues contrast downloading files with cloud-native repositories. Those repositories use object storage, analysis-ready cloud-optimized formats, and compute placed next to the data. In NASA's Cloud-Optimized Format Study (2020), Durbin, Quinn, and Shum compared COG, HDF in the cloud, Parquet, and Zarr against GeoTIFF and NetCDF-4. Those two formats hold most data in NASA's Earth Observing System Data and Information System (EOSDIS). The OGC endorsed the Zarr Storage Specification 2.0 as a community standard in 2022. COG covers two-dimensional images, and Zarr covers n-dimensional arrays.

Data cubes built on file collections

In The Australian Geoscience Data Cube: foundations and lessons learned (Remote Sensing of Environment, 2017), Lewis and colleagues design a national data cube that organizes Landsat observations as one array. In On-demand processing of data cubes from satellite image collections with the gdalcubes library (Data, 2019), Appel and Pebesma build the cube at query time from image collections. They read the images through GDAL. In Google Earth Engine: planetary-scale geospatial analysis for everyone (Remote Sensing of Environment, 2017), Gorelick and colleagues describe a managed service. It holds the archive and the compute in one place.

Parallel raster I/O

In How to apply the Geospatial Data Abstraction Library (GDAL) properly to parallel geospatial raster I/O? (Transactions in GIS, 2014), Qin, Zhan, and Zhu studied decomposition, which splits a raster into parts for parallel workers. They found that GDAL performed well under row-wise decomposition and was inefficient, and could produce incorrect output, under column-wise and block-wise decomposition. Internal tiling makes each stored block one unit of parallel work, one reason COG suits distributed reads.

Distributed spatial engines

In GeoSpark: a cluster computing framework for processing large-scale spatial data (ACM SIGSPATIAL, 2015), Yu, Wu, and Sarwat brought spatial partitioning and indexing to Apache Spark. In Spatial data management in Apache Spark: the GeoSpark perspective and beyond (GeoInformatica, 2019), Yu, Zhang, and Sarwat extended the design. That line of work became Apache Sedona, which added raster types and RS_ functions so a GeoTIFF and a vector table meet in one query. In GeoTorch: a spatiotemporal deep learning framework (ACM SIGSPATIAL, 2022), Chowdhury and Sarwat extend the same approach to deep learning on raster and spatiotemporal data.

Open problems

• Tile size. No single tile size suits both small and large windows. In the Rainier reads, a window of about 20 KB cost 2.48 MB from 1024-pixel tiles. Smaller tiles cost more requests for large windows. The OGC standard recommends 256, 512, or 1024 pixels and leaves the choice to producers.
• Metadata split between file and catalog. The red band's scale sits in STAC, outside the GeoTIFF, and the STAC offset does not match the files. Reading the file alone yields digital numbers. Applying the listed offset yields reflectance that is too low. Neither source alone exposes the mismatch.
• Pixel-is-point drift. The Copernicus DEM is PixelIsPoint and the Sentinel-2 bands are PixelIsArea. A join that ignores the flag shifts elevation by half a pixel, up to about 15 m here. GDAL RFC 33 corrects that offset for GDAL readers.
• Fragile layout. An in-place edit of a COG can break its layout. GDAL marks such a file KNOWN_INCOMPATIBLE_EDITION=YES, and the fix is to rewrite the file.
• Time and many bands. A COG holds one two-dimensional grid with bands. A time series is many files plus a catalog. Zarr and data cubes fill that gap.

What scale changes

A COG read of one file starts from a URL. For an archive, the hard part is the catalog. The Sentinel-2 L2A scene index holds a row per scene with an S3 path per band. The first step of any query is therefore a filter on footprint and date that never opens a file. Out-db rasters in Havasu keep the pixels in place. Per the Wherobots post on raster processing at scale, workers exchange only metadata, "~KB vs GB", and fetch pixels when a function reads them. Each worker runs the per-file pattern measured above, one 16 KB header and then a few tiles, across thousands of files in parallel.

Conclusions

The Rainier measurements support the opening claim: a GeoTIFF's internal layout, more than its file size, sets how many bytes a reader fetches to answer a question.

1. A GeoTIFF built as a COG can be read in parts. Every header in the Rainier set fit in one 16 KB request, and a whole-tile preview cost 739 KB of a 236.4 MB file. An untiled GeoTIFF without overviews can force a full download. Publish rasters as COG whenever they will be read over HTTP.
2. A GeoTIFF's tile size sets the cost of a small read. The 1 km summit box cost 2.48 MB in a band with 1024-pixel tiles and 54 KB in a layer with 512-pixel tiles. Choose 512-pixel tiles for files that serve small windows, and 1024 for large ones.
3. A GeoTIFF may hold raw digital numbers whose scale sits in a catalog. The STAC item lists an offset of -0.1, and the files carry none: the blue band's minimum is 39 and its 1st percentile 166. Check catalog values against dark pixels. Multiply by 0.0001 and skip the offset, or water and shadow go negative.
4. Two GeoTIFFs can anchor their pixels differently. The DEM is PixelIsPoint and the Sentinel-2 bands PixelIsArea. Ignoring the flag shifts elevation by half a pixel, up to about 15 m here. Read GTRasterTypeGeoKey before joining two rasters.
5. An archive of GeoTIFFs needs a catalog to filter before any file opens. A scene index with a footprint and date per row answers the first step of every query. Out-db rasters then fetch only the tiles each function reads.
6. GeoTIFF layouts vary inside one standard, so measure before generalising. These numbers come from one scene and one DEM tile, from two producers. Run the same range-logging test on your own files.

Related terms

• Raster vs vector data: why GeoTIFF is a raster container
• Digital elevation model: the most common single-band GeoTIFF
• Sentinel-2: distributed as one GeoTIFF per band
• Landsat: Collection 2 delivered as Cloud Optimized GeoTIFFs
• Coordinate reference system: what the GeoKeys encode
• Earth observation data: the category GeoTIFF serves

Read more from Wherobots

• Raster processing at scale: the out-of-database architecture behind WherobotsDB
• Introducing Sedona 1.5: raster and vector data processing at scale
• Measuring the Strait of Hormuz shutdown with Sentinel-2, WherobotsDB and Overture Maps
• Out-DB rasters performance guide
• Raster loaders
• Raster writers

Query and write Cloud Optimized GeoTIFFs with SQL in WherobotsDB with a Wherobots free trial at cloud.wherobots.com.