Free · runs in your browser
Find out when a video was really recorded, why it shows the wrong day, and fix the date inside the file so it sorts correctly wherever it goes.
To see when a video was recorded, open it here and look at Date & time: it lists every date the file holds, with the time zone when there is one. To change it, set Recorded (and Time zone) in Edit & clean, or move it by a set number of hours with Shift by, then press Download new file.
A video rarely has just one date. The container records when the file was written, the camera may add its own local time, an editing app adds another, and your computer keeps a separate “modified” date outside the file. When these disagree, photo libraries and file managers pick different ones, which is how a holiday clip ends up filed under 1 January 1970.
Everything happens in your browser and the video is never uploaded. The picture and sound are copied as they are; only the dates change. On an iPhone, the Photos app can also change the date in its own library: see how to change a video’s date on iPhone.
Press Open a file (Ctrl/Cmd+O) or drop the file here. The page opens on Date & time.
Check each date in the timeline and any warnings, such as a zeroed date or two dates that disagree by hours. Decide which one is right.
In Edit & clean, set Recorded to the correct date and time and pick the Time zone where it was filmed. If the camera clock was just off by a few hours, use Shift by instead.
Press Download new file (Ctrl/Cmd+S). Open What changed to see each date that was rewritten, or Inspect new file to read the new timeline.
The recording date lives inside the file, in one or more of the places below. Date & time shows them on a single timeline, so you can see at a glance whether they agree.
| Date | Where it is stored | Time zone? | Who writes it |
|---|---|---|---|
| Movie created | MP4/MOV movie header (mvhd) | No: meant to be UTC | Every MP4 and MOV writer |
| Track created | Track and media headers (tkhd, mdhd) | No: meant to be UTC | Every MP4 and MOV writer |
| Recorded (Apple) | com.apple.quicktime.creationdate key | Yes, as an offset such as +01:00 | iPhones, iPads, Macs |
| Content date | ©day atom | Sometimes | Tagging apps, some cameras |
| Segment date | Matroska DateUTC | No: UTC | Whatever made the MKV |
| File modified | Your device’s file system, not the file | Local | Your computer or phone |
The Apple key is usually the most trustworthy, because it keeps the local time and the offset together: you know it was 18:42 in London rather than 18:42 somewhere. The header dates are reliable when a phone wrote them, but many cameras put local time there while players assume UTC, which is the classic cause of clips that are an hour or more out.
ffprobe -v error -show_entries format_tags=creation_time,com.apple.quicktime.creationdate -of default=noprint_wrappers=1 clip.mov
| What you see | Likely cause |
|---|---|
| 1 January 1904 | The MP4 header date is zero; MP4 counts seconds from 1904 |
| 1 January 1970 | A zero Unix timestamp, written by an app that had no date to give |
| 1 January 2001 | A zero in Apple’s own date reference, which starts in 2001 |
| The day you received it | A messaging app made a new copy and stamped it with the time it was made, or with nothing |
| Off by exactly a number of hours | Local time stored as UTC, or a camera still set to its home time zone after travelling |
| A date years ago, such as the camera’s release year | The camera clock was never set after a battery change |
Date & time flags the zeroed dates and any dates that disagree, so you do not have to work this out yourself. If a clip arrived through WhatsApp or another app that rebuilds videos, the original recording date is usually gone entirely; check with do apps remove video metadata and set the date by hand if you know it.
MP4, MOV, M4V and 3GP files save almost instantly, because only the metadata boxes are rewritten. MKV and WebM have just one segment date and are rebuilt with a stream copy. AVI and MPEG-TS hold almost no dates at all, so there is little to change.
A browser cannot change the created or modified dates your computer shows for a file. The downloaded copy gets today’s date there, as any download does. Apps that sort by recording date use the new date inside the file; apps that sort by file date will show today.
Photo libraries read the recording date when a clip is imported and then keep their own record. Editing a copy does not change the clip already in your library: import the corrected file as a new item, check it is filed where you expect, and then delete the old one. We have not tested every library’s behaviour, so check before removing originals. Google Photos and iPhone Photos also let you change the date in the library itself, without touching the file.
Because dates are this easy to change, a date in a file proves little on its own. Disagreeing dates, an editing app’s name in the software field or a missing camera key can hint that a file was re-saved, but none of it is conclusive. The video forensics guide covers what metadata can and cannot show, and Content Credentials explains the signed alternative some cameras and apps now use.
Open it and look at Date & time. The most reliable entry is usually the recording date with a time zone, which iPhones write. If every date is zero or matches the day you received the clip, the original date was removed along the way.
Those are zero values in two common date formats. Some app wrote “no date” as a zero, and players show the starting point of the count. Set Recorded to fix it.
Only for a copy they import after the change; the item already in the library keeps its own date. We have not tested every app, so check the imported copy. Both apps can also change the date of the library item directly.
Not from a browser. Those dates belong to your computer’s file system, not the video. The new file you download gets the current date there.
No. The video and audio are copied unchanged; only the date fields are rewritten.
No. Shift by moves the recording date by the number of hours you choose, in one go. You still need to do it file by file, since the editor does not work in batches.
No. The tool reads files on your device, not online links, and a downloaded copy from those sites usually carries the download or processing date rather than the recording date.