ExifToolGui V6 — Frank Bijnen’s maintained continuation of Bogdan Hrastnik’s Windows front-end for Phil Harvey’s ExifTool — is distributed two ways: portable executables you simply unzip and run, and an installer that sets the program up and can fetch ExifTool for you. The two routes produce the same program, but they differ in exactly the places that cause confusion: what happens with ExifTool, and which Windows build you end up with. This page lays out the differences from the V6.3.12 release itself, then the 32-bit versus 64-bit question, so you can pick deliberately instead of re-downloading later. Both routes are linked from our download page; more guidance sits in the Troubleshooting hub.

What you actually download in each case

The V6.3.12 release offers four assets. The portable route gives you a single executable per architecture: ExifToolGUI_X64.exe for 64-bit Windows (21,758,464 bytes, as measured for this site) or ExifToolGUI.exe for 32-bit Windows (15,870,976 bytes). The installer route gives you ExifToolGUI_install_6.3.12.1.exe — the updated installer asset; the original 6.3.12.0 installer is the same program, and the .1 update changed only the installer (it downloads the ExifTool package from SourceForge during install if selected, with no functional changes to the GUI, per the release notes). The portable tradition is old in this program: the original v5 GUI already needed no installation — unzip it anywhere, make a shortcut, and settings go to an .ini file beside the executable rather than the registry. V6 keeps its settings the same way (ExifToolGUIV6.ini).

The decisive difference: ExifTool

Neither program is usable without ExifTool, and here the routes genuinely diverge. The portable executables do not bundle ExifTool at all — it is a separate required download that you must obtain, rename (exiftool(-k).exe becomes exiftool.exe) and pair yourself, keeping the exiftool_files folder with the exe. The installer can fetch ExifTool during setup: you choose the zip by Phil Harvey (downloaded and renamed into the install folder for you) or the self-installing package by Oliver Betz. So the portable route is not worse — it is more manual. Users who hit the ‘ExifTool not found’ error are disproportionately portable users who reasonably assumed the engine was inside. If that is you right now, the fix is five minutes of pairing, detailed in the not-found guide — or, if the installer’s fetch itself failed, pair it manually after installing.

32-bit vs 64-bit: which build your Windows needs

Match the build to your Windows, with one helpful asymmetry: 64-bit Windows runs both builds, while 32-bit Windows runs only the 32-bit build. The release names make the mapping explicit — ExifToolGUI_X64.exe is the Win64 portable, ExifToolGUI.exe is the Win32 portable. If you are on 64-bit Windows (the common case today), take the X64 portable, or let the installer decide: on Win64, the installer installs the Win64 files by default. There is one deliberate exception, straight from the V6 documentation: pass the /Win32 switch to the installer to force the Win32 files even on a 64-bit system. That switch exists for people who have a specific reason to run the 32-bit build on a 64-bit machine — if you do not have such a reason, the default is the right answer. What you should not do is mix pieces casually: whichever route you take, keep each program’s file set together (the GUI’s files in its folder, exiftool.exe with its exiftool_files folder), because partial moves are the root of most pairing failures.

So which should you choose?

• Choose the installer if you want the ExifTool pairing done for you, you are setting the program up once on your main PC, and you are happy for it to live in an installed location with its settings file there. The installer’s architecture choice is also automatic on 64-bit Windows.
• Choose the portable build if you want the program on a USB stick or in a folder you control, you work on more than one PC, or you prefer software that writes its settings beside itself and touches nothing else. Accept that pairing ExifTool is a manual step — once per location.
• Either way, you end up with the same V6.3.12 program, the same GPL-3.0 licence (the licence verified for Bijnen’s fork), and the same requirement: ExifTool present, correctly named, with its folder. Switching routes later costs nothing but a re-download and a re-pairing.

One shared caveat closes the comparison: both routes are Windows-only. The V6 documentation describes Windows 7 and 8 support and highly recommends Windows 10 or 11; there is no portable trick that makes this GUI a Mac or Linux program. Cross-platform needs are a different conversation — see ExifToolGui on Linux for the working options there.

Frequently asked questions

Is the portable version missing features?

The release notes draw the portable/installer line at distribution and at the ExifTool fetch — not at features. The portable penalty is manual pairing, not reduced capability. The one component to keep with the program is the map’s WebView2Loader.dll; if the map matters to you, keep the extracted file set intact, as the map page in the Troubleshooting hub explains.

I installed with the installer on 64-bit Windows but want the 32-bit build. How?

Re-run the installer with the /Win32 switch. The V6 documentation states that Win64 systems get Win64 files by default and that /Win32 forces Win32 files — that switch is the supported way to make the exception.

Can I switch from portable to installed later?

Yes. The program’s settings live in an .ini file (ExifToolGUIV6.ini) rather than deep system state, and your photos are never tied to the distribution route. Re-pair ExifTool after the switch — the pairing is per location — and continue where you left off.

The V6 installer for ExifToolGui — Frank Bijnen’s maintained continuation of Bogdan Hrastnik’s Windows front-end for ExifTool — offers to fetch ExifTool for you during setup. When that fetch fails, you are left with a GUI and no engine: the program is installed, but the separate program it drives is missing. The good news is that nothing about the installer route is magic. The manual pairing is the same pairing the installer performs, done by hand, and it always remains available. This page explains what the installer was trying to do, then walks the manual steps. Files for both programs are linked from our download page; more fixes live in the Troubleshooting hub.

What the installer download step actually does

ExifTool is a separate, required program — Phil Harvey’s command-line tool and Perl library, which has no GUI of its own. At install time, the V6 installer gives you a choice of how to obtain it: the ExifTool zip by Phil Harvey, which the installer downloads and renames into the install folder, or the self-installing package by Oliver Betz. One detail worth knowing: the updated installer asset, versioned 6.3.12.1, was released specifically so that the ExifTool package is downloaded from SourceForge during install if selected — and the release notes state explicitly that this installer update brought no functional changes to the GUI itself. So if your installer’s download step failed, the failure is in fetching a file, not in your PC’s compatibility with the program. Fetch the file yourself and the result is identical.

The manual pairing, step by step

• 1. Finish or close the installer. The GUI side can stay exactly as installed; you are only adding the missing engine.
• 2. Download the ExifTool Windows zip yourself from the download page. The current version is 13.59 (the 64-bit zip measures 11,183,675 bytes). Which version to choose — and why the production release is a different number — is explained in Which ExifTool Version Should You Pair.
• 3. Extract the whole zip before moving anything. Inside you will find the executable under its shipped name, exiftool(-k).exe, plus a folder named exiftool_files.
• 4. Rename exiftool(-k).exe to exiftool.exe (or to plain exiftool, if your Windows hides extensions). This rename is the step the installer normally does for you, and it is mandatory: the (-k) name is for drag-and-drop use, the GUI drives the renamed file.
• 5. Move the exe and the exiftool_files folder together to where the GUI expects its engine — ExifTool’s own documentation is explicit that if you move the exe, the exiftool_files folder must move with it.
• 6. Start ExifToolGui and test: select a photo and confirm its metadata loads in the panels. Reading works means the pairing works, and saving an edit then works on the same foundation.

If the test in step 6 fails, do not reinstall at random — diagnose with the ExifTool not-found guide, which checks the name and the folder pairing in isolation. In practice, manual pairing fails for the same two reasons installer pairing would: the rename was skipped during the hurry to finish setup, or the exiftool_files folder was left behind in the extraction folder when the executable was moved on its own. Both take under a minute to put right once identified.

Verifying the file you fetched

Because the point of this page is fetching a file the installer could not, it is worth thirty seconds of verification. The exiftool-13.59_64.zip downloaded for this site’s research measured 11,183,675 bytes, and its SHA-256 — 44b512b25af500724ba579d0a53c8fc5851628b692dd5e5d94ae4a15c2cba9ec — matches the value in Phil Harvey’s published checksum file for 13.59 exactly. The publisher provides checksums for each release (checksums-13.59.txt for this one), so you can compare the file you downloaded against the publisher’s own record rather than trusting any intermediary, this site included. A file whose size is short of the measure above was truncated in transit — download it again in full before pairing.

The other installer option, for next time

If the Harvey zip route fails repeatedly on your connection, the installer’s alternative exists for a reason: the self-installing ExifTool package by Oliver Betz. The Windows builds of ExifTool are based on Oliver Betz’s launcher work, and he provides self-installing versions of the executables — choosing that option at install time changes who packages the engine, not which engine you get. Whichever route supplies it, the end state the GUI cares about is the same: a correctly named exiftool.exe with its exiftool_files folder beside it. The distribution question on the GUI side — whether you should be using the installer at all — is covered in Portable vs Installer.

Frequently asked questions

The installer failed at the download step. Is my installation broken?

No. The GUI is installed; only the optional fetch of a separate program failed. Pair ExifTool manually with the steps above and the installation is complete — the end state is the same one a successful installer fetch would have produced.

Can I just copy an exiftool.exe from another PC?

You can move the engine, with one condition from ExifTool’s own documentation: the exiftool_files folder must move with the exe. Copy both together, keep the name exiftool.exe, and the pairing survives the move.

Why does the installer mention SourceForge?

Because that is where the files are served from: the download links on exiftool.org currently redirect to SourceForge to reduce load on the project’s own server, and the 6.3.12.1 installer update fetches the ExifTool package from SourceForge during install when that option is selected.

The map in ExifToolGui — the V6 continuation, by Frank Bijnen, of Bogdan Hrastnik’s Windows front-end for ExifTool — is the one feature with its own extra requirements. Manual geotagging depends on it: you position the map, and the GUI writes that location to your selected files. When the map panel stays blank or never loads, the cause is almost never your photos. It is the map’s own supporting pieces: in V6, the map is an OpenStreetMap view rendered through Microsoft’s Edge WebView2 technology, and the V6 documentation lists exactly what that needs. This page checks those pieces in order. The rest of the fix series is in the Troubleshooting hub, and current program files are on the download page.

What the V6 map needs — and what it does not

From the V6 documentation’s requirements section: WebView2Loader.dll and the Microsoft Edge (WebView2) runtime are required only for the OpenStreetMap map feature. They are explicitly optional extras for everything else. Two conclusions follow, and both are useful. First, if the rest of ExifToolGui works — files load, metadata reads and saves — but the map does not, your ExifTool pairing is fine and you should not disturb it; the fault is confined to the map’s components. Second, if you never use the map, a missing WebView2 piece is not a defect in your setup at all. The original v5 GUI used a GoogleMap panel; V6 replaced that approach with the OpenStreetMap/WebView2 combination, which is why advice written for the old version does not apply here.

Check 1: WebView2Loader.dll is present with the program

WebView2Loader.dll is the loader library that connects the GUI to the Edge runtime. If you run the portable build and at some point moved only the executable out of its extracted folder, the DLL can be left behind — the same partial-move mistake that breaks the ExifTool pairing when exiftool_files is separated from exiftool.exe. The fix is the same habit: keep the program’s files together. Re-extract the portable download in full, or reinstall with the installer, and check that WebView2Loader.dll sits with the program files before testing the map again. Our Portable vs Installer comparison explains what each distribution contains and how the pieces are laid out.

Check 2: the Microsoft Edge (WebView2) runtime is installed

The DLL is only the loader; the actual rendering is done by the Microsoft Edge (WebView2) runtime on your PC. Windows 11 machines and up-to-date Windows 10 machines commonly have this runtime already, because other programs depend on it too — but ‘commonly’ is not ‘always’, and a machine without it shows exactly this symptom: everything works except the map. Treat the runtime as a Windows component to confirm, not a setting inside ExifToolGui: there is no map switch in the GUI that substitutes for it. If the runtime is absent, installing it is a system-level step done once, outside the GUI, after which the map feature has what it needs. The runtime is a Microsoft component; obtain it through Microsoft’s own channels, not bundled downloads from third-party sites.

Check 3: be on V6.3.12 for the map fixes

The map itself changed in the current release. The V6.3.12 release notes (May 8, 2026) record that the MapTiler baselayers were updated to V4, a Hybrid satellite layer was added, and label sizes were fixed. If your map loads but its layers or labels misbehave on an older V6 build, updating is the sourced fix — the release directly addresses the map stack you are looking at. Version 6.3.12 also improved HEIC support and fixed a style-change crash; the full list is in ExifToolGui V6.3.12: What’s New. Note what updating cannot fix: if WebView2Loader.dll or the Edge runtime is missing, a newer GUI still lacks its map components. Check 1 and Check 2 come first.

Check 4: the map needs to reach its tile services

Stated plainly, as a general fact about how web-based maps work: an OpenStreetMap view displays map tiles fetched from online services — in V6’s case with MapTiler baselayers — so the map panel needs a working internet connection at the moment you open it, through the WebView2 component. Offline, or behind a connection that blocks the component, the panel has nothing to render even when every file is in place. Test on an ordinary open connection if you can; a map that loads there but not on a restricted network has told you the answer. This is a property of online maps generally, not a defect in your installation. While you work through these checks, the rest of the program remains fully usable — including geotagging from a GPX track log, which does not depend on the visual map at all.

Frequently asked questions

The map is blank but everything else works. Is my ExifTool pairing broken?

No. Reading and writing metadata does not use WebView2 at all. A working GUI with a blank map points at the map’s own pieces: WebView2Loader.dll beside the program, the Edge (WebView2) runtime installed, and a connection the tile services can be reached through.

Do I need the map to geotag photos?

Not necessarily. The map is for manual, visual geotagging — placing files at the map position. ExifToolGui also geotags in batch from a GPS track log file, a workflow that never opens the map panel. The map is one route to coordinates, not the only one.

I have the original V5 GUI. Do these checks apply?

Only partly. V5’s map was a GoogleMap panel with different plumbing; the WebView2 and MapTiler details here are V6 facts. If you are still on the original line, V5 vs V6 explains what changed and why the maintained fork is the version to troubleshoot on a modern PC.

ExifToolGui edits photo metadata by writing to the file itself, through Phil Harvey’s ExifTool. When Windows or the storage medium will not let the file be written, the edit cannot land — and the refusal has nothing to do with the GUI. This page explains the three ordinary reasons a file is locked or read-only, how to tell them apart, and the clean way to work around each one. A note on sourcing: the locking and read-only behaviours described here are general facts about how Windows and removable media work, stated as such — they apply to any program that modifies files, and ExifToolGui is simply the program you happen to be using. More fixes are collected in the Troubleshooting hub; the program itself is on the download page.

Case 1: the file itself is marked read-only

Windows files carry a read-only attribute. While it is set, programs are refused when they try to modify the file — the file can be opened and read, but not changed. Photos acquire this attribute in ordinary ways: copied from a disc, restored from a backup, or set deliberately long ago and forgotten. The check is direct: right-click the file in Windows Explorer, open Properties, and look at the Read-only checkbox at the bottom of the General tab. If it is ticked, clear it, apply, and make your edit again in ExifToolGui. For a whole folder of photos, the same attribute can be cleared for the folder’s contents in one operation from the folder’s Properties. If the attribute keeps coming back, the files are likely being re-copied from a read-only source each time — which is Case 3.

Case 2: the file is open in another program

A file in active use can be locked against changes by the program using it. Viewers, editors, and background tools that are reading or uploading the file can all hold it open. The symptom differs slightly from the read-only attribute: the file’s Properties look normal, nothing is ticked, yet writes fail while a particular program is running and succeed once it is closed. The diagnostic is simply to close candidate programs — start with whatever you opened the photo in — and retry the edit. If you edit photos straight from a folder that a sync service watches, be aware the service may hold files while it uploads them; pausing the sync or working on a local copy removes that variable. This is also the first thing to rule out when only some files in a batch refuse: those are usually the ones something else is holding.

Case 3: the location or the medium is read-only

Sometimes neither the file nor any program is at fault — the place the file lives refuses writes. The common versions, stated as general storage facts:

• Memory cards with a lock switch: many SD cards have a small physical slider; in the locked position the card is read-only to every program. Slide it to the unlocked position and reinsert the card.
• Discs and read-only media: files on a CD or DVD cannot be modified in place at all. Copy them to your PC first, then edit the copies.
• Folders without write permission: system folders, other users’ folders, and some network locations accept reads but not writes. Working on a copy in a folder of your own sidesteps the question entirely.
• Files copied from read-only sources can inherit the read-only attribute described in Case 1, which is why the two cases so often arrive together.

The universal workaround, and the working habit this site recommends for metadata editing in general, is: copy the photos to a normal folder on your PC, edit the copies in ExifToolGui, and only then move them where they belong. That one habit removes the medium, the permissions and most locking variables from the equation at once.

How this connects to edits not saving

A locked or read-only file is the most common underlying cause when ExifToolGui changes appear not to save: the GUI issues the write, ExifTool attempts it, the operating system refuses it. If your problem presents as edits vanishing rather than an explicit refusal, run the isolation routine in ExifToolGui Changes Not Saving — it tests one local file on a clean pairing and tells you within a minute whether you are dealing with a file problem or a program problem. And if reading metadata fails as well as writing, suspect the pairing before the files: the not-found guide covers the rename and exiftool_files checks. One reassurance to end on: a refused write leaves your photo untouched. Locked and read-only failures are frustrating precisely because they are safe — nothing was half-written.

Frequently asked questions

Can ExifToolGui override a read-only file for me?

No — and it should not. The read-only attribute and file locks are the operating system’s rules, and the GUI works within them like any other program. Clear the attribute, close the program holding the file, or edit a copy in a writable folder.

Only some files in my batch failed. Why those?

Because locking and attributes are per-file. The failures are the files that were open elsewhere, marked read-only, or sitting somewhere unwritable. Check one failed file individually — its Properties and what else has it open will usually explain the whole group.

Is editing copies instead of card originals really necessary?

It is the reliable pattern, not a strict rule. Working on copies in a local folder removes card locks, media limits and permission questions in one step, and your originals stay untouched until you are happy with the result. The GUI program files themselves are on the download page if you are setting up fresh.

You edited a date, a caption or a set of keywords in ExifToolGui, and afterwards the file shows the old values — or never took the new ones at all. ExifToolGui (the Windows front-end for Phil Harvey’s ExifTool, continued as V6 by Frank Bijnen) writes metadata by handing the job to ExifTool, so a save that silently does not happen usually traces back to one of a short list of causes: the write never reached the file, the file or its location would not accept a write, or the pairing underneath the GUI is broken. This page works through those causes in the order to check them. The full fix series is in the Troubleshooting hub, and the program files are on the download page.

Understand the write path first

In the V6 GUI, the Metadata panel’s Workspace is the editing surface: you define which tags are shown, edit values inline, and save them to all selected files. Two practical consequences follow. First, an edit applies to the files you have selected — if the file you later inspect was not in the selection when you saved, it was never written, however correct the values looked on screen. Second, the value you see in a panel is a display of what ExifTool read; after saving, re-read the file (select it again, or reopen the folder) before concluding the write failed. A stale display and a failed write look identical until you refresh the reading. Only when a refreshed reading still shows the old value do you have a genuine save problem — and those divide into the three causes below.

Cause 1: the file or its location will not accept writes

Stated plainly, as a general fact about how Windows and storage media work rather than a quirk of this program: a file marked read-only cannot be modified, a folder you do not have write permission for cannot accept modified files, and media that is physically or logically read-only — a locked memory card, a disc, a network location mounted read-only — refuses writes no matter which program asks. ExifTool writes through the same rules as every other program. So before suspecting the GUI, check the file’s properties for the read-only attribute, and test the location: copy the photo to a normal folder on your PC, edit the copy, and see whether the change saves there. If it does, the original location was the problem. That whole family of cases has its own page: File Locked or Read-Only in ExifToolGui.

Cause 2: another program has the file open

A file that is open in another application — a viewer, an editor, a sync tool uploading it — can be locked against modification while it is open. As a general operating-system behaviour, the write then fails or is refused even though nothing about the file looks read-only. The check costs nothing: close other programs that might hold the photo, make the edit again in ExifToolGui, and re-read the file. If the change now saves, you have found the cause and the permanent fix is simply to edit files that are not in use elsewhere. The locked-file page linked above covers the variations of this, including files on cards and external drives.

Cause 3: the ExifTool pairing underneath is broken

Every write the GUI attempts is executed by ExifTool. If the pairing is wrong — the executable still named exiftool(-k).exe instead of exiftool.exe, or the exiftool_files folder separated from the exe when one of them was moved — operations that depend on ExifTool cannot complete, and edits have nowhere to go. The tell-tale sign is that reading metadata also misbehaves, or the GUI reported a not-found error earlier and it was dismissed. Do not keep retrying saves on a broken pairing: fix the foundation first with the ExifTool not-found guide, verify that a file’s metadata loads cleanly, and only then test a small edit on one file and re-read it.

A safe test routine that isolates the cause

• Pick one ordinary JPEG on your PC’s own drive, in a folder you created — not on a card, not in a synced folder.
• Confirm the reading works: select the file and check its metadata appears. If not, fix the pairing (Cause 3) before anything else.
• Make one small edit in the Workspace — a keyword is ideal — and save it to the selected file.
• Re-select the file and confirm the new value is what ExifTool now reads back.
• If the test file saves but your real files do not, the difference is the files or their location: work through Causes 1 and 2 on those files specifically.

This routine separates a program problem from a file problem in about a minute, and it does so without risking a batch of real photos on an untested setup. Once saving works, batch work is safe to resume — the GUI was designed from its first version to modify multiple selected files at once. If the test file will not save even on a clean pairing and a local folder, compare your distribution choice in Portable vs Installer and make sure you are running the current V6.3.12 build from the download page.

Frequently asked questions

The panel shows my new value. Why does the file still have the old one?

The panel shows what you typed; the file holds what was written and then read back. Save the edit to the selected files, then re-select the file so the GUI re-reads it. If the read-back still shows the old value, the write did not land — work through the three causes above.

Do edits apply to one file or all selected files?

The Workspace workflow saves edited values to all selected files — that is the program’s documented batch design. The flip side is that a file outside the selection is not changed, which is a selection issue, not a save failure.

Could my antivirus or Windows be the reason?

This site publishes only causes it can source. The documented, checkable causes are read-only or locked files, locations without write access, and a broken ExifTool pairing. Those three cover the realistic cases; check them before looking further afield.

ExifToolGui is the Windows front-end for Phil Harvey’s ExifTool — the original GUI by Bogdan Hrastnik, continued today as V6 by Frank Bijnen on GitHub. When it will not start at all, the cause is usually something plain about the setup rather than something deep about your PC: an incomplete download, the wrong build for your Windows, a version of Windows outside what V6 documents, or a missing ExifTool pairing that stops the program at launch. Work through the checks below in order. If you have not installed yet, the known-good files are linked from our download page; the rest of this series lives in the Troubleshooting hub.

First, separate two different failures

A GUI that opens and then complains is not the same problem as a GUI that never opens. If ExifToolGui starts and reports that ExifTool was not found, the program itself is fine — its engine is missing or misnamed, and the fix is the pairing: rename exiftool(-k).exe to exiftool.exe and keep the exiftool_files folder with it, as the not-found guide explains step by step. The original GUI’s documentation already noted that the program shows an error at startup when the ExifTool preparation is wrong, so a launch-time error message about ExifTool points at the pairing, not at the GUI. The checks below are for the other case: the window never appears, or the program closes again immediately.

Check your Windows version against what V6 documents

ExifToolGui is Windows-only software — there is no Mac or Linux build of either the original or the V6 fork. The V6 documentation states that the GUI should run on Windows 7 and 8 (32- and 64-bit), and that using Windows 10 or 11 is highly recommended. If you are on an older or unusual Windows setup, you are outside the configuration the current documentation describes, and upgrading the GUI will not change that. On Windows 10 or 11, platform support is not your problem — move on to the file checks. (On a non-Windows system entirely, the honest options are different software; see ExifToolGui on Linux for how that works out in practice.)

Check the file you downloaded is complete

An interrupted download produces an executable that Windows cannot run properly. The V6.3.12 release files were downloaded and measured for this site on 2026-10-23, so you can compare sizes exactly: the portable Win64 executable, ExifToolGUI_X64.exe, is 21,758,464 bytes, and the portable Win32 executable, ExifToolGUI.exe, is 15,870,976 bytes. If your file is noticeably smaller, the download was cut off — download it again in full rather than trying to repair it. This check matters more than it sounds: a truncated file is one of the most common reasons a freshly downloaded program does nothing when launched.

Check you have the right build for your Windows

V6.3.12 ships two portable executables: ExifToolGUI.exe (Win32) and ExifToolGUI_X64.exe (Win64), plus the installer. A 64-bit Windows runs either build; a 32-bit Windows can only run the Win32 build. If you are unsure which Windows you have, the Win32 portable executable is the one that runs on both. The installer makes this choice for you: on 64-bit Windows it installs the Win64 files by default. Choosing between the installed and portable routes is covered in full in Portable vs Installer, including the /Win32 installer switch. If the GUI ran before and stopped after you tidied its folder, suspect a partial move: for the portable program, keep the whole extracted set together, and remember its settings live in an .ini file beside the executable (ExifToolGUIV6.ini for V6) — deleting files from the program folder can break a setup that was working.

Update to V6.3.12 if you run an older V6

V6.3.12 (released May 8, 2026) is the current release, and its notes include a fix for an access violation when changing styles — a crash-class bug in the program itself. If your copy is an older V6 build and it closes unexpectedly, moving to the current release is a legitimate diagnostic step, not a superstition: you remove a known crash from the list of suspects. Download the current files from the download page, keep your photos untouched — the GUI only edits metadata when you ask it to — and test the new build with the same folder. What changed in this release is summarised in ExifToolGui V6.3.12: What’s New.

Frequently asked questions

ExifToolGui opens, shows an error about ExifTool, and closes. Is that this problem?

It is the pairing problem wearing a startup costume. The original documentation warns that the GUI shows an error at startup if the ExifTool preparation is wrong. Fix the pairing first — correct name exiftool.exe, exiftool_files folder beside it — using the not-found guide linked above.

Do I need to install anything else for the GUI itself to run?

The documented requirements are ExifTool (required, separate) and, only if you want the map feature, the WebView2 pieces: WebView2Loader.dll plus the Microsoft Edge (WebView2) runtime. A missing map component affects the map, not the program’s startup — that case is covered by the map troubleshooting page in the Troubleshooting hub.

Should I just reinstall Windows components or edit settings?

Nothing in the program’s documentation calls for that, and this page will not invent fixes its sources do not support. The documented failure points are the pairing, the build, the platform and the completeness of the download. Check those four first; they account for the realistic cases.

ExifToolGui is a Windows graphical front-end for ExifTool — and that sentence explains this error. The GUI written originally by Bogdan Hrastnik and continued today as V6 by Frank Bijnen does not contain ExifTool itself. Phil Harvey’s ExifTool is a separate download, and when ExifToolGui cannot find a correctly prepared exiftool.exe where it expects one, it reports that ExifTool was not found. This is the single most common setup failure with this program — it shows up in this site’s search data as the query exiftool not found — and in almost every case the fix is not a reinstall or a setting. It is completing the pairing properly. If you do not have both pieces yet, start from our download page, then work through the checks below. More fixes like this one live in the Troubleshooting hub.

Why the GUI and ExifTool are two downloads

ExifTool is a platform-independent Perl library plus a command-line application by Phil Harvey. It has no graphical interface of its own. ExifToolGui is a third-party Windows front-end that sends your edits to ExifTool and shows you the results. The V6 documentation states the requirement plainly: ExifTool is a required, separate download. The portable V6 executables do not bundle it. Only the V6 installer can fetch ExifTool for you during setup, and even then it is downloading the separate program — your choice at install time is the ExifTool zip by Phil Harvey, which the installer downloads and renames into the install folder, or the self-installing package by Oliver Betz. So a fresh portable copy of the GUI with no ExifTool beside it is not broken. It is simply unpaired, and this error is how it tells you.

Check 1: the file must be renamed to exiftool.exe

This is the step most people miss. The Windows package of ExifTool does not ship a file called exiftool.exe. Inside the zip, the executable is named exiftool(-k).exe. The (-k) form is meant for double-clicking and drag-and-drop use: you drop files onto it to view their metadata. For command-line use — which is exactly how ExifToolGui drives it — ExifTool’s own documentation says to rename exiftool(-k).exe to exiftool.exe (or simply to exiftool, if your Windows is set to hide file extensions). If the file in your folder is still called exiftool(-k).exe, the GUI will not recognise it as its engine, no matter how many times you point the folder at it. Rename it, keeping the name exact, and start the GUI again.

Check 2: the exiftool_files folder must travel with the exe

The renamed executable is not self-contained. ExifTool’s Windows documentation states that if you move exiftool.exe, you must also move the exiftool_files folder that came in the same zip. A very common way to break a working setup is tidying up: copying just the exe into a tools folder, or into the GUI’s folder, and leaving exiftool_files behind in the Downloads folder or the extraction folder. The pairing then looks right — a file named exiftool.exe is present — but the program behind it cannot run properly. The reliable habit is to extract the whole zip first, rename the exe inside the extracted folder, and then move the exe and the exiftool_files folder together, as one unit, wherever they need to live.

Check 3: rebuild the pairing cleanly if it is still not found

If the name and the folder both look right and the error persists, rebuild the pairing from a clean extraction rather than patching a half-moved one:

• Download a fresh ExifTool Windows zip from the download page (the current version is 13.59; see which ExifTool version to pair for the production-versus-latest distinction).
• Extract the entire zip to a folder of your choice before renaming or moving anything.
• Rename exiftool(-k).exe to exiftool.exe inside that folder.
• Keep exiftool_files beside the exe — move both together if you relocate them.
• Start ExifToolGui and test with one photo: select a file and check that its metadata loads. Metadata appearing in the panels means the pairing works.

If you used the portable GUI, also read Portable vs Installer — it explains which pieces each distribution does and does not bring with it. And if the GUI itself now refuses to open at all, that is a different failure: work through ExifToolGui Won’t Start next.

If you installed with the installer instead

The installer path avoids the manual rename because the installer can download ExifTool during setup and place it, renamed, into the install folder. If you chose that option and still see a not-found error, the download step itself is the suspect — an interrupted fetch during setup leaves the GUI installed without its engine. That case has its own page: Installer Can’t Download ExifTool walks through pairing the engine manually afterwards, which is always an option because the manual pairing is the same pairing, just done by hand.

Frequently asked questions

I downloaded ExifTool. Why does the GUI still say it is not found?

Most likely the executable still carries its shipped name, exiftool(-k).exe. ExifToolGui looks for exiftool.exe. Rename the file exactly, make sure the exiftool_files folder sits beside it, and restart the GUI.

Does the portable version of ExifToolGui include ExifTool?

No. The portable V6 executables do not bundle ExifTool; it is a separate required download. Only the installer can fetch ExifTool during setup, if you select that option.

Can I keep exiftool.exe anywhere I like?

What matters is that the GUI can find the correctly named executable and that the exiftool_files folder moves with it — ExifTool’s own documentation makes that pairing a condition of moving the exe at all. Keep the two together and the location is a matter of your own organisation.