Raster Resolution & File Size Calculator

Raster resolution describes how many pixels cover a given area of ground — the smaller the pixel, the higher the detail. In remote sensing and GIS, resolution is expressed as the Ground Sampling Distance (GSD): the real-world length represented by one pixel on the ground. A drone survey at 5 cm GSD captures far more detail than a Sentinel-2 scene at 10 m GSD, but the resulting file is vastly larger.

Knowing the expected file size before you start processing is critical. A 50 cm pixel drone survey over a 10 km × 10 km area produces a 3-band 8-bit raster with 400 million pixels — roughly 1.1 GB uncompressed and 550 MB in a LZW-compressed GeoTIFF. Planning for this upfront prevents disk-full errors mid-pipeline and helps you choose between processing on a local workstation or a cloud machine with attached storage.

The formula is straightforward: divide the extent in each direction by the pixel size. If your study area runs from 400000 to 410000 metres (Easting) and from 5700000 to 5710000 metres (Northing) in a UTM projection, and your target pixel size is 10 m, the output raster will be 1,000 columns wide and 1,000 rows tall — one million pixels per band.

This tool uses math.Ceil to round up rather than truncating partial pixels. This matches the behaviour of GDAL, QGIS, and most raster processing tools when you specify an exact pixel size against a target extent. A 1,001.5 pixel result becomes 1,002 pixels, not 1,001 — the extra half-pixel is filled with the nodata value at the edge.

The most common mistake is a unit mismatch: entering extent values in metres and a pixel size in decimal degrees (or vice versa). If your result shows millions of pixels in one dimension, your extent and pixel size use different units. The calculator flags this with a warning when either dimension exceeds 200,000 pixels.

GeoTIFF with LZW compression is the standard for most GIS workflows. It embeds the coordinate reference system (CRS), nodata value, and spatial extent into the file header, so any GIS tool can read the projection automatically. LZW compression is lossless and typically reduces file size by 40–60% on continuous raster data.

Cloud-Optimized GeoTIFF (COG) adds an internal overview pyramid and tiles the data so web applications can stream only the portion of the raster they need. The overhead is roughly one-third of the compressed base size — so a 600 MB LZW GeoTIFF becomes about 800 MB as a COG. If your raster will be served via a tiled map API or stored in cloud object storage (AWS S3, Google Cloud Storage), COG is the right choice.

PNG is a good choice for classified or thematic rasters — land cover maps, binary masks, or labelled outputs — where lossless compression works especially well on data with many repeated values. PNG does not embed CRS metadata, so it must be accompanied by a world file (.pgw) or re-projected in GIS software.

JPEG should never be used for analysis-ready remote sensing data. Its lossy compression introduces artefacts that corrupt spectral values, making band ratios like NDVI unreliable. JPEG is only appropriate for visual-only RGB basemaps where a small degradation in pixel values is acceptable.

File size scales with the square of the linear resolution improvement. Halving the pixel size from 10 m to 5 m quadruples the number of pixels — and quadruples the raw file size. Going from Sentinel-2 (10 m) to Pléiades (0.5 m) over the same extent multiplies pixel count by 400, turning a 290 MB file into a 116 GB file. This is why high-resolution satellite imagery is always delivered as small tiles rather than continent-wide mosaics.

Bit depth has a linear effect: switching from 8-bit to 16-bit doubles the raw file size. Float32 quadruples it. Elevation data (DEMs) almost always uses 32-bit float to preserve metre-level precision across the full range of terrestrial elevations. This is why a 1 m DEM over a 50 km × 50 km area requires about 10 GB before compression — and why LiDAR DEMs are typically processed as tiled outputs rather than one giant file.