Google Earth Engine lets you work with raster data stored in your own
[Google Cloud Storage (GCS)](https://cloud.google.com/storage) buckets. By
using [Cloud Optimized GeoTIFFs (COGs)](https://cogeo.org/), you can access
and analyze your data directly in Earth Engine without ingesting it as an Earth
Engine asset.

This approach offers several benefits, especially for managing large datasets
or integrating Earth Engine into broader Google Cloud workflows or external
tools and platforms.

## Why use Cloud Storage and COGs?

- **Flexibility and interoperability:** Keep your data in standard Cloud Storage buckets where it can be accessed by other tools and services. Whether you upload the data directly or export it from Earth Engine, Cloud Storage serves as a single source of truth for both Earth Engine and external workflows.
- **Data control and egress:** Storing data in Cloud Storage provides standard object storage management capabilities. This lets you download, migrate, or share your data using Cloud Storage features like [Requester Pays](https://cloud.google.com/storage/docs/requester-pays) or [public buckets](https://cloud.google.com/storage/docs/access-control/making-data-public), and manage access using standard [Cloud IAM](https://cloud.google.com/storage/docs/access-control/iam).
- **Flexible scaling:** Avoid Earth Engine [storage limits](https://developers.google.com/earth-engine/guides/usage#adjustable_quota_limits). Cloud Storage provides virtually unlimited, self-service storage scaling to petabyte scale.
- **No ingestion wait:** Registering a COG completes rapidly because Earth Engine only reads the metadata (such as projection and dimensions) from the file header for indexing and validation. The actual pixel data remains in Cloud Storage and is read on-demand during computation, eliminating the need for a separate ingestion task.

> [!NOTE]
> **Note on costs:** For noncommercial users, Earth Engine asset storage (though limited) is available at no cost. Using Cloud Storage will incur standard storage and data transfer charges.

## COG workflows in Earth Engine

Earth Engine supports bidirectional workflows with COGs on Cloud Storage: you
can read COGs directly from Cloud Storage into Earth Engine, and you can
write computation results from Earth Engine directly to Cloud Storage as COGs.

### Reading COGs from Cloud Storage

To bring Cloud Storage-hosted COGs into Earth Engine, you have two options:

1. **Direct loading
   ([`ee.Image.loadGeoTIFF()`](https://developers.google.com/earth-engine/apidocs/ee-image-loadgeotiff)):**
   Load a single image directly using its Cloud Storage URI. Each computation
   or map-tile request reads the file's current version, but map tiles
   already rendered are cached, so after you replace a file a map can show a
   mix of old and new tiles; append `#<generation>` to the URI to pin a
   specific version. This is best for quick tests, ad hoc analysis, or
   temporary data:

   ### JavaScript

       var image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif');

   ### Python

       image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif')

   For complete examples, see
   [images from Cloud Optimized GeoTIFFs](https://developers.google.com/earth-engine/guides/image_overview#images_from_cloud_geotiffs).
2. **Registered assets:** Register one or more COGs as an
   Earth Engine asset using an upload manifest (see the
   [COG registration guide](https://developers.google.com/earth-engine/guides/cog_registration)). This is the recommended path
   for production workflows, especially when building image collections.

| Feature | Direct load (`loadGeoTIFF()`) | Registered asset (manifest) |
|---|---|---|
| **Setup** | None (just a Cloud Storage URI) | Manifest (Python client, CLI, or REST) |
| **Performance** | **Standard** (reads header on read) | **Optimized** (indexed at creation) |
| **Management** | No asset created | Counts against asset count quota, not storage. |
| **Use case** | Prototyping, ad hoc analysis | Production workflows needing fast reads. |

### Writing COGs to Cloud Storage

To save Earth Engine computation results as COGs in your Cloud Storage bucket,
use the
[`Export.image.toCloudStorage()`](https://developers.google.com/earth-engine/apidocs/export-image-tocloudstorage)
batch export function (see [exporting
images](https://developers.google.com/earth-engine/guides/exporting_images#cloud_optimized_geotiff)) and set
the `cloudOptimized` parameter to `true` in `formatOptions`. This tells Earth
Engine to compile the image and write it directly to your Cloud Storage bucket
as a fully compliant COG.

## Supported Cloud Storage bucket locations

For Earth Engine to access your Cloud Storage bucket, the bucket **must** be
located in one of the following data center regions or multi-regions:

- The `us` multi-region
- Any US dual-region that includes `us-central1`
- The `us-central1` region

If your bucket is placed in any other regional data center, Earth Engine will
reject registration and read requests. Earth Engine accesses COGs stored
exclusively in Google Cloud Storage buckets. External cloud storage providers
and generic HTTP URLs are not supported.

## Earth Engine COG export specifications

When exporting analytical results from Earth Engine using
[`Export.image.toCloudStorage()`](https://developers.google.com/earth-engine/apidocs/export-image-tocloudstorage)
with `cloudOptimized: true` in `formatOptions`, Earth Engine's built-in exporter
automatically applies the following standards:

- **File structure:** Generates a BigTIFF (`BIGTIFF=YES`) with internal tiling (`TILED=YES`) and copies all overviews to the beginning of the file.
- **Automatic overviews:** If the output raster dimensions are 512x512 pixels or larger, Earth Engine automatically builds five levels of power-of-two overviews (`[2, 4, 8, 16, 32]`). Earth Engine dynamically selects the overview resampling method based on the output pixel data type: **cubic** resampling for floating-point images and **nearest-neighbor** resampling for all other integer or discrete images.
- **Default compression and tiling:** Earth Engine exports COGs with 256x256 pixel block tiling and LZW compression (`COMPRESS=LZW`). Compression and tile dimensions cannot be customized in `formatOptions`.
- **Automatic sharding:** If an exported raster is large (exceeding 4 GiB uncompressed), Earth Engine automatically breaks the export into multiple spatial tiles named `baseFilename-yMin-xMin` (see [large file exports](https://developers.google.com/earth-engine/guides/exporting_images#large_file_exports)).
- **Override sharding limits:** To export large rasters (up to a hard ceiling of 16 GiB uncompressed and 131,072 pixels per edge) as a single file without sharding, specify `fileDimensions` inside `formatOptions`. Each dimension must be a positive integer multiple of the tile size (256 by default, for example, `[65536, 65536]`). Because `fileDimensions` sets the maximum file dimension rather than the output bounding box, passing a large ceiling forces the export into a single file without requiring exact grid calculations. You can also pass `skipEmptyFiles: true` to prevent generating empty background tiles.
- **Optimization trade-offs:** When configuring large exports, evaluate the trade-off between file count and export speed. Specifying smaller `fileDimensions` or `shardSize` produces more file fragments but maximizes parallel processing across backend workers, resulting in faster export completion times. Conversely, overriding limits to generate a single large file simplifies file management and data sharing, but can increase export execution times due to single-file assembly and I/O bottlenecks. Very large single-file COG exports approaching the 16 GiB uncompressed limit (especially images that don't compress well) may also exceed temporary storage capacity during overview and COG assembly; if an export fails, consider sharding into smaller files or [converting a standard GeoTIFF export externally](https://developers.google.com/earth-engine/guides/cog_overview#customizing_cog_creation_outside_earth_engine).

### Customizing COG creation outside Earth Engine

While exporting directly with `cloudOptimized: true` is the simplest way to
generate ready-to-use COGs for most workflows, you can also export a standard
GeoTIFF (`cloudOptimized: false`, the default) and convert it to a COG yourself
using external tools like GDAL. A two-step export and conversion workflow can be
useful when you need to:

- **Customize compression and layout:** Tailor block sizes (such as `512x512`), predictors, overview resampling methods, or compression codecs (such as `ZSTD`) to your dataset (see [best practices for preparing external COGs](https://developers.google.com/earth-engine/guides/cog_overview#best_practices_for_preparing_external_cogs) and [prepare your COGs](https://developers.google.com/earth-engine/guides/cog_registration#prepare_your_cogs)).
- **Avoid capacity errors on massive single-file exports:** Skipping overview generation and COG layout rewriting during export reduces memory and temporary storage overhead, making very large single-file exports less likely to hit capacity limits.
- **Reduce Earth Engine export execution time:** Offloading overview building and COG formatting to your own compute environment shortens the Earth Engine export phase.

## Best practices for preparing external COGs

COGs generated by common geospatial tools (such as GDAL, Rasterio, QGIS, ArcGIS,
or R's `terra` package) generally work in Earth Engine as long as they use a
[supported compression scheme and pixel data type](https://developers.google.com/earth-engine/guides/cog_overview#compression_overviews_and_creation_options).
The following guidelines can help you organize files and tune compression and
layout settings for optimized storage and performance.

### Internal tile dimensions

Always generate internally tiled rasters. Earth Engine requires square,
power-of-two tiles between 16x16 and 2048x2048 pixels. Dedicated COG exporters
(such as GDAL's `COG` driver with `-of COG`) automatically tile images into
512x512 pixel blocks (`-co BLOCKSIZE=512`), whereas standard GeoTIFF exporters
(`-of GTiff`) require explicit tiling (`-co TILED=YES`) and often default to
256x256 blocks. Tiles that are too small require many separate reads from Cloud
Storage to cover an area, while tiles that are too large force Earth Engine to
download and decompress more data than a request needs. 512x512 tiles strike a
good balance between the two.

### Choosing file dimensions

When deciding whether to store a dataset as a single COG or split it into
multiple files, balance the number of files against the size of each file:

- **Avoid thousands of tiny files:** Reading a region that spans hundreds of small files requires separate Cloud Storage requests and header reads for each file, which increases latency.
- **Avoid a single massive file:** Storing a continental or global dataset in one giant file can limit parallel read throughput when many workers read from the same object at once. There is also a hard limit: Earth Engine reads at most the first 10000000 bytes (10 MB) of a file when loading or registering it, and everything it needs (all IFDs, including the tile offset and byte-count tables, which grow with the number of tiles and, for band-interleaved files, the number of bands) must fall within that range. An image with hundreds of thousands of tiles, or a GeoTIFF larger than 10 MB whose IFDs are at the end of the file rather than the front, fails to load. To stay under the limit, use larger tiles (up to 2048x2048) or split the image into several COGs registered as an `ee.ImageCollection`.
- **Recommended file size:** When splitting a large dataset into multiple files, aim for individual files between roughly 2000x2000 and 5000x5000 pixels (about 20 MB to 500 MB compressed). Note that each `Tileset` in a COG asset manifest references a single Cloud Storage URI, so individual files are registered as separate `ee.Image` assets in an `ee.ImageCollection` rather than mosaicked inside a single COG asset.

### Single-band versus multi-band files

- **One file per band:** Useful for multispectral or hyperspectral imagery when workflows typically only read a subset of bands (for example, computing NDVI from red and near-infrared bands). Separate single-band COGs can still be combined into a single multi-band `ee.Image` asset by listing multiple `tilesets` in the registration manifest. Separate files are also required when bands have different pixel resolutions (such as Sentinel-2's 10 m, 20 m, and 60 m bands), because a single COG file can only have one pixel size across all of its bands.
- **Multi-band files (pixel versus band interleave):** Earth Engine supports both pixel-interleaved (`INTERLEAVE=PIXEL`, the default in GDAL's `COG` driver) and band-interleaved (`INTERLEAVE=BAND`) multi-band COGs:
  - **Pixel interleaving (`INTERLEAVE=PIXEL`):** Stores all bands for a spatial tile together in a single compressed block. This is well suited for datasets with a few bands that are almost always read together (such as RGB imagery), because a single range request fetches all bands. However, if a query reads only one band from a pixel-interleaved file, Earth Engine must still fetch and decompress all bands in that tile.
  - **Band interleaving (`INTERLEAVE=BAND`):** Stores each band's tiles in separate compressed blocks so Earth Engine can fetch and decompress only the requested bands. In GDAL, `-co INTERLEAVE=BAND` is supported by the `COG` driver starting in GDAL 3.11 (and in all GDAL versions when using the `GTiff` driver). Don't use `INTERLEAVE=TILE`.

### Compression, overviews, and creation options

- **Compression:** Earth Engine supports COGs compressed with `ZSTD`, `DEFLATE` (`ZLIB`), `LZW`, `PACKBITS`, `JPEG` (for 8-bit data), or `NONE` (uncompressed). `LZMA`, `WEBP`, `LERC`, and `JXL` (`JPEG-XL`) are not supported for COG-backed assets; to use files compressed with these codecs in Earth Engine, [ingest them as standard assets](https://developers.google.com/earth-engine/guides/image_upload) instead. While many COG exporters (such as GDAL's `COG` driver) default to `LZW` compression with no predictor, we recommend Zstandard (`ZSTD`) compression (in GDAL, `-co COMPRESS=ZSTD`) with a compression level of `16` (or `18`--`22` when smaller file sizes outweigh longer compression times, using `-co LEVEL=16` for the `COG` driver or `-co ZSTD_LEVEL=16` for the `GTiff` driver). Combine `ZSTD` with a predictor (`-co PREDICTOR=YES` in the `COG` driver, or `-co PREDICTOR=2` for integers and `-co PREDICTOR=3` for floats in the `GTiff` driver).
- **Overview placement and resampling:** Ensure all Image File Directories (IFDs) and power-of-two overviews are located at the front of the TIFF file so Earth Engine and web map viewers can read overviews in a single range request. Dedicated COG exporters (such as GDAL's `COG` driver) build and place overviews at the front of the file by default. Note that GDAL's `COG` driver defaults to `CUBIC` overview resampling unless the image has a color table; for categorical or discrete data (such as land-cover classifications or QA bitmasks), pass `-co OVERVIEW_RESAMPLING=NEAREST` (or `MODE`) so zoomed-out overviews don't interpolate invalid class values.
- **Nodata and masks:** Earth Engine automatically masks pixels matching the file's `GDAL_NODATA` tag (set with `-a_nodata` in GDAL; `NaN` is also supported for floating-point data) or a `missingData` value specified in the registration manifest (which overrides `GDAL_NODATA`). Earth Engine also supports internal 1-bit TIFF transparency masks that have matching reduced-resolution mask overviews. Standard extra alpha bands (`ExtraSamples`) are read as regular image bands rather than automatic masks.
- **Supported pixel data types:** Earth Engine supports `uint8`, `int8`, `uint16`, `int16`, `uint32`, `int32`, `int64`, `float32`, and `float64` COGs (`uint64`, `float16`, complex numbers, and sub-byte integer types are not supported).
- **BigTIFF and multi-threading:** Always pass `-co BIGTIFF=YES`. GDAL's default BigTIFF detection estimates file size before compression and can choose classic TIFF for a file that ends up exceeding its 4 GB limit, producing a corrupt output; the extra header space BigTIFF uses is negligible. Also pass `-co NUM_THREADS=ALL_CPUS` to parallelize compression across all available CPU cores.

The following examples convert a GeoTIFF into an optimized COG using the
unified `gdal raster convert` CLI (available in GDAL 3.11+) or
`gdal_translate`. Omit `INTERLEAVE=BAND` on GDAL versions earlier than 3.11,
and add `OVERVIEW_RESAMPLING=NEAREST` for categorical data:

    # Using the GDAL 3.11+ unified CLI
    gdal raster convert src.tif dst.tif \
      -f COG \
      --co BIGTIFF=YES \
      --co BLOCKSIZE=512 \
      --co INTERLEAVE=BAND \
      --co COMPRESS=ZSTD \
      --co LEVEL=16 \
      --co PREDICTOR=YES \
      --co NUM_THREADS=ALL_CPUS

    # Using gdal_translate (all GDAL versions)
    gdal_translate src.tif dst.tif \
      -of COG \
      -co BIGTIFF=YES \
      -co BLOCKSIZE=512 \
      -co INTERLEAVE=BAND \
      -co COMPRESS=ZSTD \
      -co LEVEL=16 \
      -co PREDICTOR=YES \
      -co NUM_THREADS=ALL_CPUS

> [!NOTE]
> **Note:** For datasets where minimizing storage size is critical (such as archival digital elevation models), you can increase compression to `LEVEL=22`, though compression will be significantly slower even on multi-core machines.

## Cost considerations and storage classes

When analyzing registered COG assets, reads from Earth Engine don't incur
Cloud Storage read operation or data retrieval charges on your Google Cloud
project.

You are billed by Cloud Storage primarily for standard monthly **at-rest data
storage (GB/month)** and any external client data transfer or network egress
fees (depending on your bucket location and client networking configuration).

### Storage class recommendations

- **Standard storage (recommended):** Standard storage is best suited for active Earth Engine workflows. Because it has no minimum storage duration rules, you can freely overwrite, update, or delete temporary COGs without incurring early deletion penalties. Furthermore, if you or your collaborators access the bucket using desktop GIS software, GDAL scripts, or machine learning notebooks outside of Earth Engine, Standard storage incurs zero data retrieval fees.
- **Nearline, Coldline, and Archive storage:** All Cloud Storage classes provide the same low-latency access and throughput as Standard storage, so there is no read performance penalty when using colder storage tiers in Earth Engine. While Earth Engine reads from these tiers also don't incur data retrieval fees, Cloud Storage enforces strict minimum storage durations (30 days for Nearline, 90 days for Coldline, 365 days for Archive). Modifying or deleting files prior to their minimum duration triggers early deletion surcharges. Additionally, accessing cold objects from any external client tool incurs costly data retrieval surcharges.

> [!IMPORTANT]
> **Important:** Because Earth Engine reads from COGs don't incur data retrieval fees, your Cloud Storage costs stay predictable regardless of how often an analysis reads the data.

For detailed pricing and minimum duration policies, see the
[Google Cloud Storage Pricing Guide](https://cloud.google.com/storage/pricing).

## High-level workflow

Typical workflows for using COGs in Earth Engine involve the following steps:

**For importing external data:**

- **Optimize:** Convert your raster files to COG format using external tools (such as GDAL, local workstation scripts, or cloud processing pipelines).
- **Upload:** Upload the COGs to a Cloud Storage bucket in a [supported location](https://developers.google.com/earth-engine/guides/cog_overview#supported_cloud_storage_bucket_locations).
- **Permissions:** Ensure you and any project collaborators have Cloud Storage read access to the files (see [COG
  permissions](https://developers.google.com/earth-engine/guides/cog_registration#configure_permissions)).
- **Register:** Use the Python client library, `earthengine` command-line tool, or REST API to register the COGs as Earth Engine assets (see [COG
  registration](https://developers.google.com/earth-engine/guides/cog_registration)).

**For exporting results:**

- **Export:** Run a batch export from Earth Engine to Cloud Storage with `cloudOptimized` set to `true` (see [exporting images](https://developers.google.com/earth-engine/guides/exporting_images)).
- **Register (optional):** Register the exported COG back into Earth Engine as a new asset for further analysis (see [COG registration](https://developers.google.com/earth-engine/guides/cog_registration)).

Ready to get started? Follow the detailed
[COG registration guide](https://developers.google.com/earth-engine/guides/cog_registration) to register your
first asset. For answers to common questions, see the
[COG section of the FAQ](https://developers.google.com/earth-engine/faq#cogs).