How to Use ExifTool: Commands With Real Examples (2026)

What Is ExifTool?

ExifTool is a free, open source command-line application and Perl library for reading, writing and editing metadata in almost any file type. It was written and is still maintained by Phil Harvey, and version 13.59 shipped on 27 May 2026. It reads EXIF, GPS, IPTC, XMP, JFIF, GeoTIFF, ICC Profile, Photoshop IRB, FlashPix, ID3 and more, plus the proprietary maker notes that Apple, Canon, DJI, GoPro, Nikon, Sony and two dozen other manufacturers bury in their own files.

That last part is what separates it from every online EXIF viewer. Those tools parse the standard tags and stop. ExifTool knows that a DJI drone writes flight altitude and gimbal angle into a private block, and that an iPhone stores a burst identifier that links photos taken seconds apart.

The name undersells it. EXIF is one metadata standard among many, and most of what ExifTool finds in a PDF or a DOCX is not EXIF at all. Treat it as a universal metadata reader that happens to be named after its first job.

My honest take: do not bother with the GUI wrappers. They expose a fraction of the functionality, and the command line is four flags deep at most for everything in this guide.

How to Install ExifTool on Kali, macOS and Windows

On Kali, Parrot and any Debian-derived system, the package is named after the Perl library rather than the binary, which trips people up:

sudo apt update && sudo apt install libimage-exiftool-perl

Kali currently ships 13.55, close enough to upstream for anything you will do with it. The binary installed is exiftool, not libimage-exiftool-perl, so apt search exiftool returning a package name that looks wrong is expected.

On macOS, Homebrew handles it in one line (the formula was at 13.55 at the time of writing), and there is an official .pkg installer on the project site if you prefer:

brew install exiftool

Windows users get a standalone executable from exiftool.org that needs no Perl installation. Download the 64-bit zip, extract it, and rename exiftool(-k).exe to exiftool.exe so it runs from a terminal instead of pausing for a keypress. Keep the exiftool_files folder next to the executable when you move it into your PATH, because the exe does not run without it. Both steps are in the install notes and almost everyone misses one of them.

Confirm the install and check what you actually got:

exiftool -ver

How to Use ExifTool: The Commands Worth Memorizing

Every ExifTool command follows one pattern: exiftool [options] [-TAG ...] FILE_or_DIRECTORY. Options change how output looks, -TAG picks what to read, and -TAG=value writes. With nothing but a file name, it dumps every tag it can find, formatted for humans:

exiftool photo.jpg

On a modern smartphone photo that is 150 lines or more, which is unreadable. Three flags fix it. -G prefixes each tag with its group, -s switches to short tag names that you can copy straight back into another command, and -a shows duplicate tags instead of hiding them:

exiftool -G -s -a photo.jpg

Output looks like this (trimmed), with the group in brackets:

[File]          FileType                        : JPEG
[EXIF]          Make                            : Apple
[EXIF]          Model                           : iPhone 14 Pro
[EXIF]          DateTimeOriginal                : 2026:03:14 09:22:41
[EXIF]          GPSLatitudeRef                  : North
[EXIF]          GPSLatitude                     : 38 deg 43' 15.62"
[EXIF]          GPSLongitudeRef                 : West
[EXIF]          GPSLongitude                    : 9 deg 8' 22.10"
[Composite]     GPSPosition                     : 38 deg 43' 15.62" N, 9 deg 8' 22.10" W

Notice that GPS tags sit in the EXIF group, and that GPSPosition is a Composite tag: ExifTool calculates it from the raw coordinates and their N/S and E/W references. Use -G1 instead of -G if you want finer labels such as [GPS] and [IFD0].

To pull one tag rather than all of them, name it with a leading dash. Tag names are not case sensitive, which saves a lot of guessing:

exiftool -GPSPosition -Model -DateTimeOriginal photo.jpg

Two more flags earn their place. -u extracts unknown tags, meaning fields ExifTool recognizes the structure of but has no name for, and -ee extracts metadata from embedded data, such as the timed GPS track inside a drone or dashcam video. They are how you find the things somebody assumed nobody would look for:

exiftool -a -u -g1 suspicious.jpg
exiftool -ee3 -p '$gpslatitude, $gpslongitude, $gpstimestamp' flight.mp4

In practice the first command is the one I run on any file that seems interesting. The -g1 grouping puts related tags together, so an oddity in a private maker note block stands out instead of scrolling past in an alphabetical wall. The second prints one line per GPS sample, which turns a video into a track log. When you truly want everything, the ExifTool docs suggest adding -ee3 -api RequestAll=3, because the default read skips a few slow or embedded sources.

GPS, Serial Numbers and What Metadata Gives Away

Metadata leaks are not theoretical, and the classic case is worth knowing because it took minutes rather than months to unravel. In December 2012, Vice published a photo of fugitive John McAfee taken on an iPhone 4S. The GPS coordinates in the EXIF data placed him beside a restaurant pool near Rio Dulce, Guatemala. McAfee first claimed he had doctored the EXIF data himself, then admitted he really was in Guatemala the next day. Nobody hacked anything. Someone downloaded the image and read the tags.

These are the fields that carry weight in an investigation:

• GPSLatitude, GPSLongitude, GPSPosition. Composite coordinates, often accurate enough to name a building. -c "%+.6f" turns them into signed decimal degrees (+38.721006, -9.139472) you can paste straight into a map.
• SerialNumber and LensSerialNumber. These tie separate photos to one physical camera body, which is how anonymous image sets get linked together.
• DateTimeOriginal versus FileModifyDate. The first is when the shutter fired, the second when the file was last written. A gap between them usually just means the file was copied or edited. A DateTimeOriginal later than the file date deserves a closer look: tampering is one explanation, a wrong camera clock is another.
• Author, Creator and Producer. In PDFs and Office documents these routinely hold an internal username matching the corporate account format, which feeds straight into an email guess.
• Software. The exact application and version that wrote the file. On a document from a target organization, that is a free look at their software estate.

Documents are the underrated target here. A PDF exported from a workstation frequently records the full local file path it was saved from, which hands you a username, a directory layout and sometimes a network share name in a single line. Finding those documents is its own skill (a Google dork like site:target.example filetype:pdf is the usual start), and our roundup of free OSINT tools puts this stage in the wider reconnaissance sequence.

exiftool -Author -Creator -Producer -Company -Title report.pdf

One caution on GPS accuracy: coordinates are recorded by the device, not verified by it. A phone with a weak fix indoors can be off by a hundred meters or write coordinates from a previous location entirely. Treat GPS metadata as a strong lead, never as proof on its own.

Batch Extraction Across a Directory

One file is a warm-up. The real value shows when you point ExifTool at a folder of a few hundred images pulled from a target site and ask a question of the whole set.

Recurse through subdirectories with -r, and export to CSV so you can sort and filter in a spreadsheet:

exiftool -r -csv -c "%+.6f" -GPSPosition -Model -DateTimeOriginal -Author ./downloads > metadata.csv

The -c "%+.6f" part matters here: without it, coordinates land in the spreadsheet as degree-minute-second text that no mapping tool will import cleanly.

The -common shortcut grabs a sensible default tag set when you do not yet know what you are looking for:

exiftool -common -csv ./downloads > overview.csv

JSON output works the same way and is easier to pipe into a script:

exiftool -r -json ./downloads > metadata.json

The flag that turns this from a dump into an actual investigation is -if, which filters files by a condition before processing them. Show only the images that carry GPS data:

exiftool -r -if '$GPSLatitude' -GPSPosition -FileName ./downloads

In practice, on a few hundred press images from a company website, that command typically returns a handful of files, and those are the ones worth looking at. Everything else went through a CMS that stripped the tags on upload. Working the other way around, filtering by camera model or by date range narrows a large set to the photos taken on one device or during one week.

Restrict processing by file type with -ext when a folder holds a mix of formats:

exiftool -r -ext jpg -ext png -GPSPosition ./downloads

How to Remove Metadata With ExifTool (Without Fooling Yourself)

The defensive half of this tool matters just as much, and this is where the sharp edges are. Removing all metadata from an image is one flag:

exiftool -all= photo.jpg

Read that carefully. The syntax is a tag assignment with nothing on the right-hand side, so -all= means "set all tags to empty". Miss the equals sign and you have asked to read every tag instead of deleting them, which is a quiet failure rather than an error.

Four details decide whether this actually worked:

• ExifTool keeps your original. By default it renames the untouched file to photo.jpg_original and writes the cleaned version in its place. Publish the wrong one and you have shipped the file you meant to sanitize. Add -overwrite_original once you trust the command, or clean up afterwards with -delete_original (it asks for confirmation; -delete_original! does not).
• The file date is a tag too. Adding -P preserves the filesystem modification time, which you may or may not want. Without it, the write updates the timestamp.
• Some things survive by design. On a JPEG, -all= leaves the Adobe APP14 segment in place because removing it can change how the image renders, while it does remove the ICC color profile, so colors may shift. The Adobe segment holds no personal data, but it will still show up when you re-read the file.
• Verify, do not assume. Run exiftool -G -a on the output. Anything beyond the [ExifTool], [File] and [Composite] lines and the odd [APP14] entry deserves a second look.

Selective removal is often the better call. Stripping every tag from a professional photo destroys the copyright and color profile information the photographer wants kept. Delete only the location data instead:

exiftool -gps:all= photo.jpg

Or delete everything except one group you want to preserve, using the double-dash exclusion syntax. Keeping the ICC profile is the usual choice, since it stops colors from shifting:

exiftool -all= --icc_profile:all photo.jpg

There is no dry-run flag. The closest thing is -o, which writes the result to a new location and leaves the source untouched, so you can inspect the output before committing. And if you already wrote in place without -overwrite_original, -restore_original puts the backups back:

exiftool -all= -o cleaned/ photo.jpg
exiftool -restore_original photo.jpg

To clean an entire directory tree in one pass, with backups suppressed and file dates preserved:

exiftool -r -all= -overwrite_original -P ./to-publish

A warning worth taking seriously: run that command on a directory you did not mean to touch and there is no undo, because -overwrite_original is exactly what it says. Test it on a copy first. Every time.

ExifTool in CTF Forensics

In CTF forensics challenges, ExifTool is the second command you type after file. Flags get parked in a Comment field, a UserComment, an Artist tag or a custom XMP property often enough that skipping this step wastes an hour.

The workflow that resolves most image challenges is short:

1. Identify the real file type. file challenge.png compares magic bytes against the extension. A mismatch is a finding by itself.
2. Read every tag, including the odd ones. exiftool -a -u -g1 challenge.png surfaces duplicates and unknown fields that plain exiftool hides.
3. Extract anything binary you find. exiftool -b -ThumbnailImage challenge.jpg > thumb.jpg pulls the embedded preview out. Edited photos sometimes keep an unedited thumbnail, which is its own category of leak.
4. Move to the file structure. If the metadata is clean, binwalk and strings are next, then bit-plane analysis.

Step three deserves more attention than it gets. A JPEG thumbnail is generated once and not always regenerated after an edit, so the small preview can show what the full image was cropped or blurred to hide. That has burned real people, not just CTF players.

When the metadata comes back clean, that silence is information too. It means the payload is somewhere else in the file, and our steganography detection guide picks up the trail from there.

When ExifTool Was the Vulnerability

Parsing untrusted files is dangerous work, and ExifTool has been on the wrong end of it. CVE-2021-22204 was a flaw in the DjVu file handling that allowed arbitrary code execution when the tool parsed a crafted image. It affected versions 7.44 through 12.23, was fixed in 12.24, and NIST scored it 7.8 High. It sits in CISA's Known Exploited Vulnerabilities catalog, meaning it was used in real attacks rather than only demonstrated in a lab.

Two practical consequences follow from that.

Keep your install current, especially if ExifTool runs automatically on files users upload. A large number of web applications call it server-side to generate thumbnails or read image dimensions, and a five-year-old version in a container image is a real exposure.

Analyze genuinely suspicious files in an isolated virtual machine with no network access. This holds for any parser, not just this one. The reflex to run a tool on a sample the moment it arrives is the reflex worth breaking.

Legal and Ethical Considerations

Metadata analysis sits in a gentler legal position than most offensive techniques, because reading a file you already possess touches nobody else's system. The risk moves from computer misuse law to privacy and data protection law, and that shift catches people out.

Where This Is Fair Game

• Files from your own devices, and files a client has provided as part of a signed engagement
• Documents published on a target's own website when an OSINT scope covers them in writing
• CTF challenges and purpose-built training environments
• Sanitising your own output before you publish it, which is the most useful application here

The line that matters: geolocating a private person from a photo they posted, and acting on that location, is stalking regardless of how public the photo was. An authorised OSINT engagement documents its targets and its boundaries before the first command runs. If your scope does not name it, it is not in scope.

Frequently Asked Questions