Exercise 001
The flooded market
A viral photo claims to show market stalls under water this morning. What does the file itself say?
Briefing
This is a fictional scenario. A post from an invented account, @stallholders_watch, is spreading fast. It was published on Saturday 14 March 2026 and reads:
Stalls underwater at the market this morning.
It is attached to a photo. Your editor at a small, fictional community news desk wants to know one thing before the desk shares it: what can the file itself support, and what can it not?
You are not being asked who posted it or why. You are being asked to examine the evidence and report what it does and does not show.
The image is an illustration made for this exercise. The account, the camera and the editing software do not exist, and the metadata was written for this exercise so that you can check your answers.
Use the downloaded file, not a screenshot, because a screenshot loses the metadata.
Tools
You need a metadata tool and an online map. ExifTool is the standard. If you use it, this one command shows the tags that matter for tasks 1 to 4:
exiftool -Make -Model -Software -DateTimeOriginal -OffsetTimeOriginal -ModifyDate -GPSLatitude -GPSLongitude -GPSDateTime market-photo.jpg
Tasks
- Device and capture time. What device made the file, and when does the file say the photo was taken (date, time and time zone offset)?
- Location. What coordinates does the file contain, and what place do they point to? Name the place and say how you confirmed it on a map.
- Does the file back up the post? Compare the capture date with the date of the post. Then check whether the GPS time and the local time agree with each other.
- File history. Look at the software tag and the modification date. What do they suggest happened to the file, and what can they not tell you?
- The second image. Many photo files hold a small preview picture inside the metadata. Extract it and compare it with the main image. Describe every difference you see.
Finish with a two sentence finding for your editor. It must say what the evidence supports and what it does not.
Hints
Hint 1 (tasks 1 to 3)
Capture time and modification time are different tags. Do not use the date your file manager shows, which is usually when you downloaded the file.
Hint 2 (task 2)
Coordinates are stored as degrees, minutes and seconds, plus a letter for the hemisphere. Convert them to decimal degrees, treating south and west as negative, and paste the result into your map.
Hint 3 (task 5)
ExifTool can write the embedded preview to its own file:
exiftool -b -ThumbnailImage market-photo.jpg > preview.jpg
Solution
Solution (spoiler)
1. Device and capture time. The device is a Nimbus Mobile NM-5 Pro (a made-up device). The capture time is 18 October 2025, 07:42:10, with a time zone offset of +02:00.
2. Location. The GPS tags give about 33.9249 degrees south, 18.4241 degrees east. On a map this lands in central Cape Town, near the Grand Parade and City Hall. Any answer that places it in central Cape Town is correct.
3. Does the file back up the post? The post names no place, so the GPS position cannot be checked against the claim. The date can be checked, and it does not fit: the capture date is 147 days before the post. The GPS time is 05:42:08 UTC, exactly two hours behind the local time of 07:42, so the file is consistent with its +02:00 offset. That consistency tells you the tags agree with each other. It does not rescue the claim, because the tags say the photo was taken in October, not on the morning of the post.
4. File history. The software tag names an editor, PixelForge 4.2, and the modification date is 14 March 2026, 06:55:31, the morning of the post. This suggests the file was opened and saved in editing software after it was captured, shortly before it was posted. It cannot tell you what was changed. The camera clock or the editor’s clock could also be wrong, so this is a lead, not a fact.
5. The second image. The embedded preview shows the market in daylight with dry ground and a clear sky. The main image shows rain clouds and water covering the ground. Cameras usually write the preview at capture time. If an editor changes the main image and does not refresh the preview, the preview keeps showing the original scene.
Sample finding. The file’s own tags place the photo in October 2025 in central Cape Town, not on the morning of 14 March 2026, and its embedded preview shows a dry scene that does not match the flooded main image, which together suggest the image was altered after capture. This does not prove who made the change or why, and because metadata can be edited or forged, it should be corroborated with other sources, such as weather records for that date and other photos of the location, before the desk treats it as settled.
Debrief
Three habits this exercise is built to teach:
- A believable location does not validate the rest. The post names no place to check against, and it still fails on date and content.
- Say what the evidence does not show. The strongest findings state their limits.
- Metadata is a lead. Treat tags as one source, then look for a second, independent one.
For more on this approach, read the blog post A photo’s metadata is a witness, not a verdict.
Community walkthroughs
No community walkthroughs yet.
Submit your own
Write up your solution on your own site and send us the link. Every submission is reviewed by hand, and nothing is listed until it has been approved.