A GeoTIFF is a standard TIFF (Tagged Image File Format) image file that contains embedded geospatial metadata — specifically, the coordinate reference system (CRS), the geographic position of the image, and the pixel resolution. This means the image knows where it is on Earth. Open a GeoTIFF in a GIS tool like QGIS, and it automatically positions itself at the correct geographic location on a map. Open it in a regular image viewer, and it looks like any other photograph — the geospatial metadata is invisible but present.
GeoTIFF is the most widely used format for geospatial raster data. If you’ve worked with orthomosaics, digital elevation models (DEMs), satellite imagery, or any other georeferenced raster layer, you’ve almost certainly worked with GeoTIFFs.
What makes a GeoTIFF different from a regular TIFF
A regular TIFF stores pixel data — rows and columns of colour values forming an image. A GeoTIFF stores the same pixel data plus additional tags (using the TIFF format’s extensible tag system) that describe:
- Coordinate Reference System (CRS): Which map projection and datum the image uses (e.g., EPSG:4326 for WGS 84, EPSG:32756 for UTM Zone 56S)
- Geotransform: The geographic coordinate of the top-left pixel and the pixel size in map units
- Tie points: Specific pixel coordinates mapped to geographic coordinates
From these tags, any GIS software can calculate the geographic coordinate of every pixel in the image. A pixel at row 500, column 300 in a GeoTIFF isn’t just a colour value — it’s a colour value at a specific latitude and longitude (or easting and northing, depending on the CRS).
The metadata in practice
Here’s what the geospatial metadata typically looks like when you inspect a GeoTIFF:
| Property | Example value |
|---|---|
| CRS | EPSG:32756 (WGS 84 / UTM zone 56S) |
| Upper-left corner | 321456.789 E, 6245678.901 N |
| Pixel size | 0.02 m (2 cm GSD) |
| Image size | 15000 x 12000 pixels |
| Bands | 3 (Red, Green, Blue) or 4 (RGBA) |
| Bit depth | 8-bit (0-255 per band) or 16-bit |
| NoData value | 0 or -9999 (for areas outside coverage) |
The CRS is critical. It tells the software how to interpret the coordinates. A GeoTIFF in UTM Zone 56S positions correctly in southeastern Australia. The same pixel coordinates interpreted in a different CRS would place the image somewhere completely wrong.
Common uses of GeoTIFFs
Orthomosaics
The most common GeoTIFF you’ll encounter in drone surveying is the orthomosaic — a stitched, geometrically corrected aerial image. Photogrammetry software (Pix4D, Metashape, DJI Terra) outputs orthomosaics as GeoTIFF by default.
Digital Elevation Models (DEMs)
DEMs — both Digital Surface Models (DSMs) and Digital Terrain Models (DTMs) — are stored as single-band GeoTIFFs where each pixel value represents elevation in metres. Instead of RGB colour, each pixel contains a floating-point height value.
Satellite imagery
Landsat, Sentinel, and commercial satellite providers deliver imagery as GeoTIFFs. Multispectral satellite data typically uses multi-band GeoTIFFs with separate bands for visible, near-infrared, and shortwave infrared wavelengths.
Derived analysis layers
NDVI maps, slope analysis, aspect maps, hillshade visualisations, and other raster analysis outputs are all typically stored as GeoTIFFs.
Scanned and georeferenced maps
Historical maps and paper plans that have been scanned and georeferenced are saved as GeoTIFFs — a regular scan image with control points that tie it to real-world coordinates.
Cloud Optimized GeoTIFF (COG)
A standard GeoTIFF must typically be downloaded in full before it can be viewed. For a 5 GB orthomosaic, that means the viewer (or GIS software) needs to load the entire 5 GB file — even if you only want to see a small section.
Cloud Optimized GeoTIFF (COG) solves this. A COG is a regular GeoTIFF with a specific internal structure that enables efficient partial reading over HTTP:
- Internal tiling: The image is divided into tiles (typically 256x256 or 512x512 pixels) instead of being stored row by row
- Overviews (pyramids): Pre-computed lower-resolution versions of the image are embedded in the file
- Byte-range requests: A web server can serve specific byte ranges of the file, allowing a client to request only the tiles it needs
How COG streaming works
- The client requests the file header (a few kilobytes) to learn the image dimensions, CRS, and tile layout
- At the current zoom level, the client determines which overview level is appropriate and which tiles are visible
- The client requests only those specific tiles via HTTP range requests
- As you pan or zoom, new tiles are requested on demand
The result: a 5 GB orthomosaic can be viewed in a browser with only a few megabytes of actual data transfer — you see exactly what’s in the viewport, at the appropriate resolution for the zoom level.
Converting to COG
Most photogrammetry software now outputs COG directly (or offers it as an option). If you have a standard GeoTIFF, you can convert it using GDAL:
gdal_translate input.tif output_cog.tif -of COG -co COMPRESS=DEFLATE
For web viewing, COG is strongly preferred over standard GeoTIFF. If you’re uploading orthomosaics to a platform for client viewing, COG format will give significantly better performance.
How to view GeoTIFFs
Desktop GIS
| Software | Cost | Notes |
|---|---|---|
| QGIS | Free | Full GeoTIFF support, open source |
| ArcGIS Pro | ~$100/yr (personal use) | Industry standard commercial GIS |
| Global Mapper | ~$550/yr | Good general-purpose GIS |
| Google Earth Pro | Free | Can overlay GeoTIFF (with limitations) |
For surveyors and GIS professionals, QGIS is the standard free option. Drag a GeoTIFF onto the map canvas and it positions itself correctly.
In a browser
This is where things get interesting for client delivery. Most clients don’t have QGIS and aren’t going to install it. But GeoTIFFs can absolutely be viewed in a browser — with the right tools.
Browser-based GeoTIFF viewing typically uses one of these approaches:
- Tile server: The GeoTIFF is pre-processed into map tiles (like Google Maps tiles) and served to a web map library (Leaflet, MapLibre, OpenLayers)
- COG direct: A Cloud Optimized GeoTIFF is read directly in the browser using JavaScript libraries like GeoTIFF.js, with tiles requested on demand via HTTP range requests
- Server-side rendering: A backend service renders the requested map extent and returns an image, which the web map library displays
Each approach has tradeoffs around setup complexity, performance, and cost. For client delivery, the practical question is: do you want to manage the infrastructure yourself, or use a platform that handles it?
Sharing GeoTIFFs with clients
I wrote a detailed guide on this topic: How to Share a GeoTIFF Online. The short version:
- Don’t email the GeoTIFF. It’s too large, and the client can’t open it.
- Don’t send a Dropbox link. The client downloads it, tries to open it in an image viewer, and sees a flat image with no geographic context.
- Do use a browser-based viewer. Upload the GeoTIFF to a platform that renders it on a web map, and share a link.
Swyvl renders GeoTIFFs on a Leaflet web map automatically. Upload the file, and it’s viewable in a browser — overlaid on a basemap, zoomable to full resolution, and shareable with a link. No server setup, no QGIS installation for the client.
Coordinate Reference Systems (CRS) — the part that trips people up
The most common source of GeoTIFF problems is CRS mismatches. Here’s what you need to know:
Geographic vs. projected CRS
- Geographic CRS (e.g., EPSG:4326 — WGS 84): Coordinates are latitude and longitude in degrees. The Earth is modelled as an ellipsoid.
- Projected CRS (e.g., EPSG:32756 — UTM Zone 56S): Coordinates are easting and northing in metres. The curved Earth surface has been projected onto a flat plane.
Orthomosaics from drone surveys are almost always in a projected CRS (UTM, State Plane, MGA, OSGB) because projected coordinates are in metres, which makes measurement straightforward.
Common CRS by region
| Region | Common CRS | EPSG code |
|---|---|---|
| Global (generic) | WGS 84 | 4326 |
| Australia | MGA Zone 54-56 | 28354-28356 |
| UK | OSGB 1936 / British National Grid | 27700 |
| US (generic) | UTM Zones 10-19 | 32610-32619 |
| US (state-level) | State Plane (varies) | Varies |
| Europe | UTM Zones 28-38 | 32628-32638 |
| New Zealand | NZTM 2000 | 2193 |
What happens when the CRS is wrong
If a GeoTIFF’s CRS metadata doesn’t match the actual coordinates in the file, the image will appear in the wrong location — sometimes by metres, sometimes by thousands of kilometres. Always verify the CRS matches what your processing software used.
In QGIS, right-click the layer, go to Properties > Source, and check the CRS. If it’s wrong, you can assign the correct CRS (not reproject — assign, meaning “these coordinates should be interpreted as this CRS”).
File size considerations
GeoTIFFs can be very large. An uncompressed 3-band (RGB) orthomosaic at 2 cm resolution covering 50 hectares might be:
- Pixel dimensions: ~35,000 x 28,000 pixels
- Uncompressed size: ~2.9 GB (35000 x 28000 x 3 bytes)
- With DEFLATE compression: ~1-2 GB
- With JPEG compression (lossy): ~300-600 MB
Compression options
| Compression | Type | Ratio | Quality | Use case |
|---|---|---|---|---|
| None | N/A | 1:1 | Perfect | Archival, processing input |
| DEFLATE | Lossless | 2-4x | Perfect | General delivery |
| LZW | Lossless | 2-4x | Perfect | Alternative to DEFLATE |
| JPEG (in TIFF) | Lossy | 5-15x | Good | Web viewing, previews |
| ZSTD | Lossless | 2-5x | Perfect | Modern alternative to DEFLATE |
For client delivery, DEFLATE-compressed GeoTIFF is the standard choice — lossless compression with reasonable file sizes. For web viewing via COG, JPEG or DEFLATE compression with internal tiling provides the best performance.
GeoTIFF vs. other raster formats
| Format | Georeferenced | Open standard | Browser viewable | Compression | Common use |
|---|---|---|---|---|---|
| GeoTIFF | Yes (embedded) | Yes | Via COG/tile server | Multiple options | Universal standard |
| JPEG + world file | Yes (sidecar) | Yes | JPEG only (no geo) | Lossy | Legacy workflows |
| ECW | Yes | No (proprietary) | Requires plugin | Wavelet (excellent) | Government, large datasets |
| MrSID | Yes | No (proprietary) | Requires plugin | Wavelet | Aerial photography archives |
| JPEG 2000 | Yes | Yes | Limited | Wavelet | Some government agencies |
| PNG | No | Yes | Yes (no geo) | Lossless | Web graphics, not GIS |
GeoTIFF wins on openness, compatibility, and ecosystem support. It’s the format every tool reads and writes, which is why it’s the standard for delivery.
Practical advice for surveyors
-
Always deliver GeoTIFF for orthomosaics. It’s the format every GIS tool supports, and it contains the CRS metadata your client’s engineer needs.
-
Include the CRS in your delivery notes. Even though it’s embedded in the file, explicitly stating “CRS: EPSG:32756 (MGA Zone 56)” saves confusion.
-
Consider COG for large files. If your orthomosaic is over 1 GB and you’re sharing it via a web viewer, COG format dramatically improves the viewing experience.
-
Use a browser-based viewer for client delivery. Most clients don’t have GIS software. A shareable link that opens in a browser is always a better experience than a download link and a suggestion to install QGIS.
-
Keep the full-resolution GeoTIFF as the primary deliverable. Even if you share a web viewer link, make the original GeoTIFF available for download. Technical clients (engineers, GIS analysts) will want the raw data for their own tools.
For a complete guide on sharing GeoTIFFs with clients who don’t have GIS software, see How to Share a GeoTIFF Online. And for broader context on professional survey delivery, see How to Deliver Drone Survey Data to Clients Professionally.