Edit EXIF Metadata in a JPG
Fix a wrong date, credit a photographer, add a copyright line, or write GPS coordinates onto a scan — without touching the picture. A JPEG keeps its metadata in a header segment separate from the compressed image, so the honest way to change it is to rebuild that segment and copy the rest through byte for byte. That is what this does: the pixels in the output are bit-for-bit identical to the input, every time. Nothing is uploaded.
Drop JPG files here
JPG / JPEG only · multiple allowed · the same fields are written to all of them
How to use it
- Drop the JPGs. If you are correcting one photo, press Read existing metadata first — the fields fill in from the file and you edit from there.
- Fill in what you want written. Leave a field empty and that tag is simply not written.
- Dates use the EXIF format
YYYY:MM:DD HH:MM:SS— colons in the date part, which looks wrong and is correct. - Press Write metadata. Every queued file gets the same fields, and each result reports whether an existing block was replaced or a new one inserted, plus the byte delta.
Where metadata actually lives in a JPEG
A JPEG is a sequence of marker segments. APP0 is usually JFIF, APP1 holds
either EXIF or XMP, APP2 commonly carries the ICC colour profile, DQT holds
the quantisation tables, and after SOS comes the entropy-coded image data that is the
actual photograph. Metadata is entirely in the APPn segments before it.
So a metadata edit does not need a decoder at all. This tool walks the markers, builds a fresh
APP1 EXIF segment from your fields, and writes out: everything before the old segment,
the new segment, everything after. If the file had no EXIF, the new segment is inserted straight
after APP0, which is where readers expect it.
The EXIF block is a small TIFF file
Inside APP1, after the six bytes Exif\0\0, sits a complete TIFF structure:
a byte-order mark, a magic number, and a pointer to the first image file directory. Each directory
is a list of twelve-byte entries — tag, type, count, and then either the value itself or a pointer
to it. Four bytes or fewer go inside the entry; anything longer is written to a data area and the
entry holds the offset.
Two rules from the specification are where hand-written EXIF usually goes wrong, and both are
followed here: entries in a directory must be sorted by ascending tag number, and every value offset
must be even. Get either wrong and you produce a file that one reader accepts and the next one
rejects. Camera settings live in a sub-directory reached through tag 0x8769, and GPS in
another through 0x8825 — which is why those pointers have to be counted before any
offset can be worked out.
Related
- EXIF viewer — read everything a photo carries, including tags this editor does not write.
- Remove EXIF — strip EXIF, XMP, IPTC and comments in one pass, losslessly.
- Change DPI — the same lossless header-rewrite trick, applied to resolution.