Correct existing photo capture clocks
Choose a clock offset or recorded/actual anchor pair, select existing Exif fields, and check each corrected JPEG against the full ZIP report.
Choose one clock error and explicit correction
A camera clock was wrong across a photo batch. Add exact seconds, or give one recorded and actual wall-clock pair, then choose the existing date fields to change. Keep originals and compare every corrected copy with the complete report.
1–500 original JPEG Files, 10 MiB each and 100 MiB total; filenames up to 512 UTF-8 bytes. The picker may impose a shorter basename limit.
Exact integer seconds and recorded/actual anchors are mutually exclusive. Anchors use YYYY:MM:DD HH:mm:ss and change every selected existing field by the same wall-clock offset. No timezone inference or missing-tag creation.
- Choose all supported original JPEG photos with the same camera-clock error.
- Enter exact seconds or one recorded/actual anchor pair; select existing date fields.
- Run, compare before/after preview rows and the batch summary, then download the complete ZIP.
- Use clock-report.json and corrected copies to review every source, field, byte span and hash; check the receiving program’s date priority.
Choose fields the receiving program uses
Only DateTime, DateTimeOriginal and DateTimeDigitized can be selected. XMP dates, OffsetTime, SubSec, GPS, compressed pixels and every other byte stay unchanged. File-system dates are not edited.
DateTimeOriginal usually describes capture time; DateTimeDigitized describes digitization and DateTime is an image change date. The tool does not decide which date an organizer will display. Keep a copy of originals and inspect the complete per-field before/after report before replacing your own archive.
- Start with DateTimeOriginal when capture order is the task; select additional existing fields only deliberately.
- A camera that is 2 minutes ahead needs −120 seconds; recorded 12:02:00 and actual 12:00:00 express the same correction.
- Separate batches whose cameras have different errors.
Review the complete package
The screen previews at most 20 changed fields and copies a bounded batch summary. The ZIP contains every corrected JPEG, complete clock-report.json, formula-safe clock-changes.csv and copy.txt. Source names, indices, hashes and selected/unselected dates remain complete.
| Path | Use | Complete identity |
|---|---|---|
| corrected/photo-NNNN.jpg | Corrected editable photo copy | Only selected date value bytes differ |
| clock-report.json | Every original and changed/unselected date | Source index/name/size/SHA, field offsets and output SHA |
| clock-changes.csv | All changed fields for spreadsheet review | Quote-all formula-safe source labels; literal names in JSON |
| copy.txt | Bounded batch summary | Counts and applied offset; not a per-source report |
Recognize support and retry without partial results
Baseline 8-bit SOF0, one interleaved scan and terminal EOI; exactly one classic little- or big-endian Exif TIFF. Progressive JPEG, BigTIFF, multiple Exif sections, MPF, JUMBF, trailers and unsupported structures refuse the entire queue.
Per photo: 4096 markers, 5 supported IFD roles, 512 entries per IFD and 1500 entries; queue total 100000 entries. Selected date values must be existing 20-byte ASCII fields with valid years 0001–9999.
Malformed, unsupported, missing-field, over-budget, cancelled or timed-out input yields no partial package. The whole operation has a 10-second deadline, including local loading and file reads; retry the same selected originals after cancellation.
Report and CSV each have an 8 MiB guard; complete binary plus text and binary plus metadata each have a 128 MiB guard. Processing stays in this browser, without uploading names or contents. Source pixels are not decoded or re-encoded by this tool.
- A valid progressive JPEG can still be outside this supported profile; choose original baseline JPEGs.
- A refused queue does not skip bad photos; fix the source or change the selected fields and rerun all originals.
- A long local load or read also consumes the same 10 seconds; cancel terminates unfinished work.
References
- Photo authors — correcting wrong camera timestamps
Complete first-person question, eleven answers and fourteen answer comments reviewed for admission. The accepted clock-offset approach and multi-camera feedback support this task; original files, browser preference, region and demand volume remain unknown.
Tools in this category
Expand a tool to see its steps, options and supported formats, then open its workspace.
Correct photo capture clocksApply one explicit clock correction to existing JPEG Exif dates; keep every other source byte and download the full change report.
A camera clock was wrong across a photo batch. Add exact seconds, or give one recorded and actual wall-clock pair, then choose the existing date fields to change. Keep originals and compare every corrected copy with the complete report.
Steps
- Choose all supported original JPEG photos with the same camera-clock error.
- Enter exact seconds or one recorded/actual anchor pair; select existing date fields.
- Run, compare before/after preview rows and the batch summary, then download the complete ZIP.
- Use clock-report.json and corrected copies to review every source, field, byte span and hash; check the receiving program’s date priority.
Available options
- Correction method
- Exact seconds to add · Recorded and actual clock pair
- Exact seconds to add
- 0
Positive adds time; negative subtracts time. Whole seconds only, from −315537897599 to +315537897599; every corrected year must remain 0001–9999.
- Recorded wall-clock time
- Enter as needed
- Actual wall-clock time
- Enter as needed
- Existing date fields to change
- Capture time — DateTimeOriginal · Digitized time — DateTimeDigitized · Image change time — DateTime
Select at least one. Every photo must contain every selected field; otherwise the entire queue refuses.
Capabilities and limits
- 1–500 original JPEG Files, 10 MiB each and 100 MiB total; filenames up to 512 UTF-8 bytes. The picker may impose a shorter basename limit.
- Baseline 8-bit SOF0, one interleaved scan and terminal EOI; exactly one classic little- or big-endian Exif TIFF. Progressive JPEG, BigTIFF, multiple Exif sections, MPF, JUMBF, trailers and unsupported structures refuse the entire queue.
- Per photo: 4096 markers, 5 supported IFD roles, 512 entries per IFD and 1500 entries; queue total 100000 entries. Selected date values must be existing 20-byte ASCII fields with valid years 0001–9999.
- Exact integer seconds and recorded/actual anchors are mutually exclusive. Anchors use YYYY:MM:DD HH:mm:ss and change every selected existing field by the same wall-clock offset. No timezone inference or missing-tag creation.
- Only DateTime, DateTimeOriginal and DateTimeDigitized can be selected. XMP dates, OffsetTime, SubSec, GPS, compressed pixels and every other byte stay unchanged. File-system dates are not edited.
- The screen previews at most 20 changed fields and copies a bounded batch summary. The ZIP contains every corrected JPEG, complete clock-report.json, formula-safe clock-changes.csv and copy.txt. Source names, indices, hashes and selected/unselected dates remain complete.
- Malformed, unsupported, missing-field, over-budget, cancelled or timed-out input yields no partial package. The whole operation has a 10-second deadline, including local loading and file reads; retry the same selected originals after cancellation.
- Report and CSV each have an 8 MiB guard; complete binary plus text and binary plus metadata each have a 128 MiB guard. Processing stays in this browser, without uploading names or contents. Source pixels are not decoded or re-encoded by this tool.