Practice with mock tests, learn from structured notes, and get your questions answered by a global forensic community, all in one place.
Every digital media file carries structured metadata alongside its pixel or sample data. EXIF, IPTC, XMP, and format-specific structures like MP4 atom hierarchies and WAV RIFF chunks encode timestamps, device identifiers, and editing history that can corroborate or contradict a file's claimed origin.
Last updated:
When a phone camera takes a photograph, the resulting JPEG file contains two things: the compressed pixel data, and several kilobytes of structured metadata describing how the image was made. GPS coordinates, capture time, camera model, shutter speed, focal length, the camera's serial number derivative, and sometimes the scene recognition mode the phone's AI used to adjust the exposure. This metadata record can place an image at a specific location and time with greater certainty than anything visible in the picture itself.
The problem is that metadata is easy to alter, easy to strip, and often inconsistent. An image might carry three timestamps that disagree with each other: the EXIF DateTimeOriginal, the file system modification date, and the GPS timestamp. Each of those discrepancies is a question the examiner must answer. Was the file timezone-corrected? Was it processed through software that rewrote the timestamps? Was it fabricated with a tool that guessed plausible values but got them slightly wrong?
Video and audio files have parallel structures. An MP4 file is a hierarchy of typed boxes (atoms) whose contents describe the entire timeline of the recording. A WAV file is a RIFF chunk structure that can carry metadata in INFO and BEXT chunks alongside the PCM audio samples. This topic maps the relevant metadata standards, shows where they live inside the file, and explains how inconsistencies in them become forensic evidence.
The camera writes more to every image than you can see.
EXIF metadata lives in the APP1 segment of a JPEG file, positioned immediately after the SOI (Start of Image) marker. It is structured as a TIFF IFD (Image File Directory) tree, with each field identified by a two-byte tag number, a data type, and a value. The specification was originally developed by JEIDA (Japan Electronics Industry Development Association) in 1995 and has been maintained through subsequent versions; the current widely-implemented specification is EXIF 2.32 (2019).
The fields most frequently used in forensic analysis fall into three groups. First, device identification: Make (tag 0x010F), Model (0x0110), Software (0x0131), CameraSerialNumber (MakerNote-derived), and LensModel (0xA434). Second, temporal data: DateTimeOriginal (0x9003), DateTimeDigitized (0x9004), SubSecTimeOriginal (0x9291), and GPSTimeStamp (in the GPS IFD). Third, spatial data: GPSLatitude, GPSLongitude, GPSAltitude, and GPSImgDirection.
The three timestamp tags serve different purposes and often diverge in altered images. DateTimeOriginal records when the shutter fired according to the camera clock. DateTimeDigitized records when the image was scanned or digitised (identical to DateTimeOriginal for direct digital capture). DateTime records the last modification time and is updated by software that rewrites the file. An image with DateTimeOriginal in 2021 but DateTime in 2024 is consistent with post-processing. An image with DateTimeOriginal later than DateTime is inconsistent with normal capture and software workflows and requires explanation.
GPS in EXIF is evidence, not proof. It must be checked against everything else.
GPS metadata in EXIF lives in a separate IFD pointed to by tag 0x8825 in the main IFD. It stores latitude, longitude, altitude, GPS timestamp (UTC), the direction the camera was pointing (GPSImgDirection), and the fix source (GPS, cell network, or Wi-Fi triangulation, recorded in GPSMeasureMode and GPSProcessingMethod). These fields are independent of the camera's own clock, so a GPS timestamp inconsistent with DateTimeOriginal can indicate timezone manipulation or fabrication.
GPS data is among the most easily edited EXIF fields because many desktop tools offer GPS coordinate editing explicitly for privacy or travel-log purposes. A forensic examiner therefore treats GPS evidence as a starting point for corroboration, not a terminal conclusion. The relevant corroboration sources include cell-tower records for the device, the image content itself (buildings, street furniture, vegetation), meteorological records for the claimed date and location (cloud cover, sun angle), and timestamps in any accompanying video or audio recorded around the same time.
Inside the Makernote is the camera's private record, and it is harder to fake than the public EXIF fields.
The Makernote stores data that does not fit the EXIF standard specification. Each manufacturer defines their own IFD structure inside this field, often undocumented and reverse-engineered by the forensic and photography communities. A few examples illustrate the forensic value: Canon Makernotes include the camera's internal serial number, the specific AF point used, the colour temperature measured by the AWB sensor, and the specific Picture Style setting. Nikon Makernotes include a firmware version string, the shooting mode dial position, and a VR (vibration reduction) status flag. Sony Makernotes include the scene recognition mode used by the camera's AI exposure system.
These fields are useful for two tasks. First, source verification: the Makernote of a file claimed to come from a Canon EOS 90D should contain Canon-format data consistent with that model's firmware. A Makernote in Nikon format, or a structurally malformed Makernote, is an immediate inconsistency. Second, internal consistency checking: the camera serial number implied by the Makernote can be compared across multiple images claimed to come from the same device.
| Manufacturer | Makernote identifier | Key forensic fields |
|---|---|---|
| Canon | "Canon" ASCII header | Internal serial number, AF point, colour temperature, Picture Style, lens focal length |
| Nikon | "Nikon" + version byte | Firmware version, shooting mode, VR flag, lens ID, colour balance |
| Sony | "SONY DSC" header | Scene mode, creative style, in-camera HDR flag, distortion correction flag |
| Apple (iPhone) | Structured sub-IFD | Run-time timestamp, HDR sub-image flag, panorama metadata, Portrait mode depth map reference |
A clean strip is actually rare, and partial stripping is a forgery signal in itself.
Privacy-conscious users and malicious actors both strip metadata from image files. Tools like ExifTool, ImageMagick, and platform-side processing (Twitter, WhatsApp, most social platforms strip all EXIF on upload) can remove all EXIF and IPTC data. What they cannot do is alter the pixel-level forensic signatures that the camera wrote during capture. From a forensics perspective, a stripped image is not a sanitised one: the PRNU fingerprint, CFA correlation, and JPEG quantisation table are all still present.
Partial stripping is more interesting than complete removal. Editing workflows that preserve some EXIF fields while rewriting others leave a metadata archaeology layer. A common pattern: Adobe Lightroom exports retain the CameraSerialNumber and LensMake fields from the original Makernote but rewrite DateTimeOriginal to the export time and add an XMP packet signed with a Lightroom history. If the claimed context is an unedited original, this history is contradicting that claim.
XMP history blocks are particularly informative. Applications that write XMP include an xmpMM:History entry for each action taken on the file: open, save, export, and the software name and version. A file with an XMP history showing three separate Photoshop save operations is not an unedited original, whatever the EXIF DateTimeOriginal says.
The moov atom is the index. What is missing from the index is as important as what is there.
An MP4 file is a hierarchy of typed units called boxes (or atoms in QuickTime terminology). Each box has a four-byte length, a four-byte type code, and a data payload. Boxes nest: the moov box contains trak boxes for each track, which contain mdia and minf boxes, which contain stbl (sample table) boxes that index every compressed frame.
The key boxes for forensic timeline analysis are:
A comparison of the creation time in the mvhd box with the file system timestamps (ctime, mtime) and with the GPS timestamps embedded in the udta box can reveal whether the file has been moved, copied, or re-packaged since its original creation. File system timestamps are easily altered by setting the system clock, but aligning them convincingly with all three internal timestamp sources simultaneously is much harder.
A WAV file is a filing cabinet. Checking each drawer reveals the recording's history.
WAV files use the RIFF (Resource Interchange File Format) chunk structure, originally developed by Microsoft and IBM. The file starts with a four-byte RIFF identifier, a four-byte total length, and a four-byte format identifier ('WAVE'). Inside the WAVE container, chunks are arranged as a flat or mildly nested sequence of typed records.
The mandatory fmt chunk (format chunk) defines the audio parameters: PCM or IEEE float, number of channels, sample rate, bit depth, and byte rate. The data chunk holds the actual PCM samples. Several optional chunks are forensically interesting:
A JPEG file has EXIF DateTimeOriginal set to 2020-06-01 and a GPS UTC timestamp that implies the local time was 2020-06-01 minus two hours. What is the most likely explanation for this discrepancy?
Test yourself on Forensic Audio, Video and Image Analysis with free, timed mocks.
Practice Forensic Audio, Video and Image Analysis questionsSpotted an error in this page? Report a correction or read our editorial standards.