# Photo Date Fixer

> Shift the EXIF date taken of JPEG photos by days, hours or minutes in bulk, or add a date where none exists. Image data untouched, CSV/JSON record, no upload.

- URL: https://bytescope.dev/en/photo-date-fix/
- Locale: en · Also: [ja](https://bytescope.dev/ja/photo-date-fix.md) · [zh-Hant](https://bytescope.dev/zh-Hant/photo-date-fix.md)
- Runs: The folder is opened locally by your browser. Photos are read and written on your own disk — nothing is uploaded.
- Requires: Full mode needs Chrome, Edge or Opera on desktop (File System Access API) to read a folder and write results next to it. Firefox and Safari get a reduced mode: pick the folder through a file input and download the results.
- Updated: 2026-09-08

## What it does

### Why the date taken is wrong, and why it matters

You came back from a trip and every photo is an hour off because the camera was still on home time. Or the camera's clock runs seven minutes slow and its shots interleave badly with the ones from your phone. Or a box of scanned prints has no date at all. The capture time lives in EXIF, and tools like `/photo-organizer` and `/bulk-rename` sort by it — if it is wrong, every folder and filename built on it is wrong too.

### Two modes, both built for correcting rather than rewriting

Shift: pick an offset in days, hours, minutes and seconds and every selected JPEG moves by exactly that amount. There is no free-form date field for a single file; the preview always shows original → corrected. Fill blanks: give a date (a year or year-month is enough, it is padded to the first day at 00:00:00) and the tool writes it only into files whose `DateTimeOriginal` is empty. Files that already have a date are left alone and greyed out. A scanned JPEG with no EXIF at all gets a minimal EXIF block so the date has somewhere to live. Matching two cameras automatically and time-zone conversion are planned for a later version; today you shift one camera's batch by the offset you measured.

### What is written, and what is deliberately left alone

The tool rewrites `DateTimeOriginal` and `DateTimeDigitized`, and optionally `DateTime`. Each is a fixed 20-byte ASCII field, so the new value overwrites the old one in place and the image data is not touched by a single byte. GPS timestamps, vendor dates inside the MakerNote and the file system's creation date stay as they are. If a file also carries dates in XMP, this version does not change them and the page warns you per file, because Lightroom and similar software may read the XMP date first. The first version handles JPEG only: HEIC, PNG, WebP, video and RAW come later, so iPhone HEIC shots are listed as unsupported for now.

### Copies by default, a record every time

By default the corrected files are saved as copies into a different folder you choose, subfolders included, and the originals are untouched. Overwriting in place is an option behind a second confirmation, and then the record is the only way back. Firefox and Safari cannot write into folders, so there each corrected file is offered as a download instead. Every run produces a correction record as CSV and JSON — path, field, before, after, offset, mode — and JPEG files also keep the original values in XMP under a custom namespace. Nothing is uploaded; the files are read and rewritten inside the browser. Afterwards, sort the folder with `/photo-organizer` or rename by date with `/bulk-rename`.

## Limits

Does not upload photos, change GPS or MakerNote dates, change file-system dates, or read HEIC and RAW files yet; it only rewrites the EXIF date fields of JPEG files.

## FAQ

### Are my photos uploaded?

No. The JPEG bytes are read, patched and written back in this browser tab. There is no upload endpoint; the correction record is written into the output folder or offered as a download.

### Does changing the EXIF date recompress the photo?

No. The date fields are fixed-length ASCII, so the new value overwrites the old one in place. The compressed image data is copied byte for byte.

### Can I set an exact date on one photo?

Not as a free-form field. You enter an offset and the tool applies it, or you fill in a date for photos that have none. That keeps the page a correction tool rather than a backdating tool, but it cannot stop a wrong offset: the tool does not know the real capture time.

### What about HEIC from an iPhone?

Not yet. The first version reads and writes JPEG only. HEIC, PNG, WebP, video and RAW are listed as unsupported with a reason and are planned for a later version.

### Will Google Photos or iCloud pick up the new date?

Not automatically. Cloud albums keep their own copy of the capture time, and changing the local file does not sync it back. Whether re-uploading the fixed file makes the album use the new EXIF date has not been verified, so the page does not promise it.

### How do I undo a fix?

Keep the CSV/JSON record the tool writes on every run; it lists each file, field and the value before and after. If you saved copies, the originals are still there. If you overwrote in place, the record is the only reference, which is why that option asks twice. JPEG files also carry the original values in XMP.

### Does it touch the GPS time or the camera's own notes?

No. GPS timestamps, vendor dates inside the MakerNote and the file system's creation date are never changed. Albums and organizers sort by the EXIF capture date, which is the field being fixed.

## Related tools

- [Photo Organizer](https://bytescope.dev/en/photo-organizer.md) — Sort the corrected photos into date folders once their times are right.
- [Bulk Rename](https://bytescope.dev/en/bulk-rename.md) — Rename every file in a folder from its corrected capture date.
- [EXIF Viewer](https://bytescope.dev/en/exif-viewer.md) — Read every EXIF tag to check what the date fix actually wrote.
