ExifToolGui Changes Not Saving? Causes and Fixes

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.

Similar Posts