GeoTIFF Missing Projection — How to Find and Assign the Correct CRS

A GeoTIFF with no projection information typically loses its CRS when exported from software that strips geospatial metadata. Upload the file to Projection Finder — it will analyse the bounding coordinates to identify the most likely CRS from thousands of EPSG codes, so you can then assign it using GDAL or QGIS.

You have a GeoTIFF that loads in your GIS software but lands in the wrong place — or shows up with no coordinate system at all. gdalinfo returns an empty projection string. QGIS asks you to select a CRS on import. The file is georeferenced in all the wrong ways.

This is a GeoTIFF with no projection information. It is more common than it should be, and it is fixable — but only if you know whether the coordinates are correct and the CRS label is simply missing, or whether the coordinates themselves are in the wrong system.

Why GeoTIFFs Lose Projection Information

GeoTIFF stores CRS metadata in TIFF tags alongside the pixel data. Those tags are easy to strip and easy to omit.

Conversion Tools That Strip Metadata

Non-GIS image editors — Photoshop, GIMP, Paint.NET, and most web-based converters — open TIFF files but write them back without the GeoTIFF tags. The pixel data survives intact. The georeference does not. This is the most common cause of a GeoTIFF with no projection information.

Even some GIS-adjacent tools make this mistake. Certain image compression workflows, thumbnail generators, and cloud optimisation scripts drop the TIFFTAG_GEOTIFF metadata if they are not specifically told to preserve it.

Legacy Remote Sensing Software

Older sensors and older processing pipelines write pixel coordinates and resolution into the GeoTIFF but omit the CRS definition. The file knows where its top-left corner is, but not what coordinate system those values belong to. You will see a valid geotransform in gdalinfo output but an empty Coordinate System field.

Manual or Scripted Raster Creation

When creating rasters programmatically — with NumPy arrays, rasterio, or GDAL Python bindings — forgetting to call dataset.SetProjection() produces a valid raster with no CRS. The geotransform may also be missing if SetGeoTransform() was skipped, leaving the file with no spatial reference at all.

Satellite Data Download Pipelines

Some satellite data portals or processing APIs return files with the CRS stripped at the delivery stage — especially older platforms that output raw band files and expect the user to apply georeferencing. Sentinel-2 Level-1C data in JPEG2000 format, for example, is sometimes converted to TIFF in ways that lose the embedded CRS if the conversion tool does not handle JP2 georeference properly.

How to Check If CRS Is Truly Missing

Run gdalinfo yourfile.tif and look at the output. You are looking for two sections: Coordinate System and Origin.

What a Missing CRS Looks Like

A GeoTIFF with no projection information will show something like this in the gdalinfo output:

Coordinate System is '' or Coordinate System is `'

The geotransform section may still show values under Origin and Pixel Size — those are the coordinate values without a named CRS. Or it may show the file origin at (0.0, 0.0) with a pixel size of (1, -1), which means no georeference at all.

What a Present CRS Looks Like

A correctly georeferenced file will show a full WKT block under Coordinate System. It will include PROJCS[...] for projected systems or GEOGCS[...] for geographic ones. The AUTHORITY["EPSG","XXXX"] tag at the end gives you the EPSG code directly.

The Borderline Case: CRS Present but Wrong

A GeoTIFF can have a CRS but still be broken. The metadata says EPSG:4326, but the coordinates are in metres. This is a mislabelled GeoTIFF — a distinct problem from a missing one. If your file shows a CRS in gdalinfo but still renders in the wrong location, the CRS metadata is incorrect, not absent. Check the coordinate values against the stated CRS before assuming the label is right.

How to Identify the Correct CRS from the Coordinate Extent

Once you have confirmed the CRS is missing, look at the coordinate extent from gdalinfo. The Upper Left, Lower Right, and Center values are your primary diagnostic tool.

Geographic vs Projected: The First Split

If the X values fall between -180 and 180, and Y values between -90 and 90, the coordinates are in decimal degrees — a geographic CRS. The most likely candidate is WGS84 (EPSG:4326), though NAD83 (EPSG:4269) covers North America and uses the same degree-based range.

If the X values are large integers — hundreds of thousands or millions — the coordinates are in metres and belong to a projected system. This is where it gets specific to geography.

Reading the Coordinate Range

X range	Y range	Likely CRS
-180 to 180	-90 to 90	WGS84 (EPSG:4326) or NAD83 (EPSG:4269)
100,000–900,000	0–10,000,000	UTM (zone depends on X value)
3,000,000–3,900,000	5,000,000–6,500,000	German Gauß-Krüger Zone 3
0–700,000	0–1,300,000	British National Grid (EPSG:27700)
−20,000,000–20,000,000	−20,000,000–20,000,000	Web Mercator (EPSG:3857)

For UTM, the zone can be estimated from the easting (X) value. A central meridian easting of 500,000 metres is the midpoint of any UTM zone. Values between 100,000 and 900,000 are plausible UTM eastings. The zone itself maps to a longitude band — you need to know roughly where the data comes from geographically to narrow it down.

Using Projection Finder for Ranked Candidates

Upload the GeoTIFF to Projection Finder. Even without a CRS label, the tool analyses the coordinate extent and returns ranked candidates based on known coordinate ranges for common EPSG codes. It will flag the status as GUESSED — indicating heuristic inference, not a confirmed match — and show confidence scores. You can then verify by checking whether the preview map places the raster in the correct location.

How to Assign the CRS (Without Reprojecting)

Once you have identified the correct CRS, you need to write it into the file metadata. This operation is called assigning or defining the projection — and it is critically different from reprojecting. See the next section for why that distinction matters.

Using gdal_edit.py

The gdal_edit.py script modifies GeoTIFF metadata in-place. It does not touch pixel values. Run:

gdal_edit.py -a_srs EPSG:32632 yourfile.tif

Replace 32632 with the correct EPSG code. The -a_srs flag means "assign spatial reference system". This writes the CRS into the GeoTIFF tags and is the standard command-line method.

If you also need to set the geotransform (i.e., the file has no coordinate values at all, not just no CRS label), use gdal_translate with -a_ullr to set the upper-left and lower-right corners, then -a_srs to assign the CRS.

Using QGIS

In QGIS, right-click the layer in the Layers panel and select Layer CRS → Set Layer CRS. Search for your EPSG code and confirm. This writes the CRS to the file's metadata via QGIS's GDAL backend.

Do not use the Reproject Layer option in the Processing toolbox — that is a different operation. The setting you want is under Layer CRS, not under any processing or geoprocessing menu.

Using rasterio (Python)

To assign a CRS programmatically with rasterio:

Open the file in read-write mode with rasterio.open('yourfile.tif', 'r+'), then set dataset.crs = CRS.from_epsg(32632) and close. This is the equivalent of gdal_edit.py -a_srs in Python.

Common Pitfall: Assigning vs Reprojecting

Assign when: the coordinates in the file are already in the correct system, but the CRS label is missing or wrong. You are just telling the software what the coordinates mean. No pixel values change. No coordinates are recalculated.

Reproject when: the coordinates are in the wrong system and need to be mathematically converted to a different one. Reprojection changes the coordinate values and resamples the pixel grid.

A Concrete Example

Your GeoTIFF has coordinates around X: 500,000, Y: 5,700,000. You know from context this is data from central Germany. Those coordinates are consistent with UTM Zone 32N (EPSG:32632). The file just has no CRS tag.

The correct action: assign EPSG:32632. The pixel data is already in that coordinate space.

The wrong action: run a reproject operation from "unknown" to EPSG:32632. That would attempt to mathematically transform the coordinates as if they were in some other system — producing garbage output.

If you accidentally reproject a file that needed an assignment, the resulting coordinates will be wrong, typically by hundreds of kilometres. The file will appear to cover the correct area in software that trusts the new CRS, but the actual pixel positions will not match reality.

When This Does Not Help

Assigning a CRS only works when you are confident about which CRS the coordinates belong to. If you genuinely do not know — for example, you have an unlabelled raster from an unknown source with no accompanying documentation — assigning an incorrect CRS is worse than having no CRS at all. It creates false confidence and silent errors in downstream analysis.

In that situation, you have two options: find the data's provenance (the original data supplier, project documentation, or a colleague who knows the source), or use Projection Finder to get candidate matches and visually verify each one against known landmarks before committing to an assignment.

Also note: if the file has no geotransform at all (origin at 0,0, pixel size 1×1), you are not dealing with a missing CRS label — you are dealing with a completely unreferenced raster. Assigning a CRS alone will not fix this. You will need to georeference the raster from scratch using control points.

Using Projection Finder to Detect the CRS Automatically

Projection Finder analyses GeoTIFF files in the browser. It reads the GeoTIFF tags using geotiff.js and checks for embedded CRS metadata. When a CRS is present, it shows a FOUND status with the EPSG code. When CRS is absent but coordinates exist, it analyses the extent and returns ranked GUESSED candidates. When it cannot determine anything, it returns UNKNOWN and asks you to select manually.

The map preview is the critical step. A GUESSED result with a confidence score is a starting point, not a verdict. Load the top candidate, look at where the raster lands on the map, and compare it against a known reference layer or expected geography. Only assign the CRS once you have confirmed the placement visually.

Upload your file at projectionfinder.com — no account required, all processing happens in your browser.

FAQ

Summary

1. Confirm the CRS is missing — run gdalinfo and check the Coordinate System field
2. Read the coordinate extent — degree values point to geographic CRS; metre values point to projected
3. Get candidate CRS codes — use Projection Finder for ranked matches based on coordinate range
4. Verify visually — check the map preview before committing to any CRS assignment
5. Assign, do not reproject — use gdal_edit.py -a_srs or QGIS Layer CRS to label in-place
6. Know when to stop — if provenance is unknown, do not guess; find the source data or georeference from control points

Related Guides

• Find GeoTIFF Projection — Read CRS from Any Raster File
• Find Shapefile Projection — Free .prj Checker & Fixer
• NAD83 vs WGS84 — What's the Difference?
• How to Convert WKT to EPSG Code
• What Is a .prj File and What Does It Contain?

Related Resources

• epsg.io — Search EPSG codes by name, area, or WKT
• spatialreference.org — Projection definitions in multiple formats