How to Add Geotagged Photos to Google Earth
Google Earth does not read the GPS coordinates inside a photo. Drag a geotagged JPEG onto it and nothing happens, because the location sitting in that file is invisible to the application. To add geotagged photos to Google Earth you convert them into KML first: the format Google Earth does read, which carries the coordinates alongside the picture instead of inside it.
That one fact explains almost every problem people hit here, including the pins that arrive with no picture attached and the timeline that refuses to animate. The steps below cover the conversion, then the three things that go wrong afterwards.
What Google Earth actually reads from a photo
Nothing. It reads KML and its zipped form, KMZ, and that is the whole list. The clearest evidence is Google's own tutorial on the subject: rather than opening a photo, it walks through converting geotagged photos into KML with a script that pulls the coordinates out of the image first.
Those coordinates live in the photo's EXIF block, and they are stored in a way worth knowing about before you convert anything. The latitude and longitude are always written as positive numbers. Which side of the equator and which side of the prime meridian you are on is held separately, in a one-letter reference field, N or S for latitude, E or W for longitude.
Lose that single letter in a conversion and the number survives intact while the pin lands in the wrong hemisphere, which is the classic version of "my photo is in the sea". Before converting a batch, check what the file already carries so you know whether there is anything to convert at all.
How to add geotagged photos to Google Earth
Five steps, in order. Step two only applies to photos that have no location yet.
- Open one photo and confirm it has latitude and longitude before converting the whole folder.
- For any photo without coordinates, write the coordinates into the photo first.
- Convert the folder to a KMZ using a converter that reads each photo's GPS block.
- Open the KMZ in Google Earth by double-clicking it, or through File then Open.
- Drag the loaded layer into My Places so it survives a restart.
The desktop application and Google Earth on the web both open KML and KMZ files. If a KMZ loads but the pictures do not appear, the next section is almost always the reason.
What is actually inside the KMZ file
A KMZ is an ordinary ZIP archive. Google's documentation describes it as a main KML file plus supporting files packaged with a Zip utility, and you can confirm that yourself: copy the file, change the extension to .zip, and open it.
Inside you find a single KML file at the top level, conventionally named doc.kml, and a subfolder holding the pictures. The KML does not contain your photos. It contains the coordinates and a path pointing at each image, and Google's guidance is to keep those paths relative to the archive's base folder.
Two rules follow from that, and breaking either produces the same symptom, pins that open with a broken-image icon:
- Do not rename the photos after export. The KML still points at the old filenames, and nothing warns you.
- Do not re-zip the archive with everything nested one folder deeper. Every relative path now starts in the wrong place.
There is one more rule that catches people who try to merge two exports: Google's documentation states there is only one KML file in an archive, and Google Earth uses the first one it finds and ignores anything after it. Two merged KMZ files give you half your pins and no error message.
Why your photo sits on the ground
Photos taken with altitude recorded still tend to appear flat on the terrain, and that is a default rather than a fault. KML controls height through an altitude mode, and the default value is clampToGround, which the KML reference defines as instructing Google Earth to ignore any altitude specification and drape the item over the terrain. Your recorded height is read, then discarded.
The alternative, absolute, places the item relative to sea level regardless of the actual elevation of the terrain beneath it. That sounds like the fix, and for a photo taken at sea level it is. For a photo taken in a high-elevation town it often is not: the height in the file is measured from sea level, the ground in Google Earth comes from its own terrain model, and the pin can end up buried beneath the landscape rather than floating above it.
Google's own tutorial adds the caution that makes this mostly academic: many devices do not track altitude at all and simply set it to zero. Check one file before assuming a conversion lost something.
Turning a set of photos into a timeline
This is the feature that makes the whole exercise worth it, and the one most conversions quietly fail to deliver. Google's documentation is explicit: when Google Earth opens a KML file containing a feature with a time element, it displays a time slider. Drag it and your photos appear in the order they were taken, which turns a static cloud of pins into a replayable trip.
It fails because the date in your photo and the date KML wants are written in incompatible formats.
| Where it lives | How it is written |
|---|---|
| In your photo, as the capture date | 2005:10:12 16:05:56 |
| In the KML Google Earth reads | 2007-01-14T21:05:02Z |
The photo uses colons between the parts of the date and no time zone. KML wants dashes, a T between date and time, and a zone marker. A converter that copies the photo's date across without rewriting it produces a file Google Earth loads happily and never puts on the slider, no error, just no timeline. If your pins have no slider, that is the first thing to check.
What the pins do not tell you
Google's tutorial closes with cautions that are easy to skip and worth keeping. GPS receivers built into cameras are not always accurate. Many devices record no altitude. And the coordinate in the file marks where the camera stood, not what it was pointing at. A photo of a mountain taken from ten kilometres away pins the valley, not the peak.
The related gap is direction. A plain location says nothing about which way the lens faced, so two photos taken from one spot in opposite directions are indistinguishable once they are pins on a map. Some cameras record a compass bearing alongside the coordinates; most phone photos in a typical folder do not.
None of that makes the map wrong, but it does set the limit on what it proves. If you want to understand what the file is actually storing before you trust a batch of pins, how a location is stored inside a photo covers the underlying tags, and you can pull the coordinates back out of any image to compare them against where the pin landed.
