The walkthrough video names nobody: what a move-in video actually records

Most managers now shoot a walkthrough video at move-in and again at move-out. It is the sensible habit. One continuous take, every room, a few minutes, no gaps for anyone to argue about.

A video feels like stronger evidence than a set of photos. It is longer, it is continuous, and it is harder to stage. At the level of what the file records, the opposite is true, and it is worth knowing exactly how before the file is the only thing you have left.

This is not legal advice.

What we measured

On 16 September 2026 we read the metadata out of two videos and one photograph taken with the same Android phone, plus one clip from an action camera.

The photograph carries what you would hope for. Our own checker reads it back as:

Shot on samsung Galaxy Z Fold7, with capture settings intact (ExposureTime, FNumber, ISO, FocalLength, DateTimeOriginal). Camera clock recorded 2025-12-10 15:30:37.

The maker, the model, the exposure settings, and the moment the shutter fired on the phone’s own clock, in the phone’s own time zone.

The two videos from the same phone carry, in total: a creation time, com.android.version=14, and the capture frame rate.

No maker. No model. No location. Nothing about the lens or the exposure. The action-camera clip was no better: a firmware string, and no model name at all.

So the picture names the phone that took it. The video from that same phone names nobody.

The one timestamp it does carry is not the one you think

That leaves the creation time doing all the work, and it behaves in two ways that will catch you out.

It is in UTC, not your clock. The first video’s filename says it was recorded at 21:22 on 18 August. Its creation time reads 2024-08-19T03:23:23Z. Same moment, different day.

It marks the moment you stopped recording, not the moment you started. That is the part worth writing down. Both files check out to the second:

• Video one started at 21:22:39 local and ran 42.5 seconds, so it ended at 21:23:21. The timestamp in the file is 03:23:23Z, which is 21:23:23 local. Two seconds after it ended, not forty-two seconds before.
• Video two started at 23:13:16 and ran 193.1 seconds, ending at 23:16:29. The timestamp in the file is 06:16:30Z, which is 23:16:30 local.

Two for two, within about a second and a half. The timestamp is written when the recording is closed and the file is finalised.

Put those two together and a specific, ordinary thing happens. A manager does the final walkthrough late on the last night of a tenancy — say it starts at 23:13 on 1 January, which is exactly what the second file records. The video’s own timestamp says 2 January. The tenancy ended on the 1st. The only date inside the file is the day after the date you will write in the letter.

Nobody faked anything. Nobody lied. The file just does not say what everyone assumes it says.

This is not an argument against shooting video

Video is good at things photographs are bad at. It shows extent and context — that the stain runs the length of the hallway, that the crack is one crack and not three. It shows continuity, which is its own kind of proof: you can see that nobody stopped, moved something and started again. A long continuous take of a real place is still awkward to fabricate convincingly.

The point here is narrower and entirely about the file. Video is excellent at showing what a place looked like and poor at establishing who recorded it, on what, and when. For a photograph, those last three are the questions the file can usually answer by itself. For a video, they are the questions you have to answer some other way.

That gap has started to matter more, because “it’s a video, so it must be real” is retiring as an assumption. Short AI-generated clips are now good enough to pass a glance, which is the whole reason the sentence “those photos are AI” has become free to say — and it is just as free to say about a video.

What to do instead: shoot stills as well

The fix is not complicated and costs about ninety seconds.

1. Shoot the walkthrough video as you already do. Keep it. It is your record of extent and context.
2. In each room, also take three or four still photographs with the same phone: the room, and close-ups of anything you would ever charge for. The stills are what carry the device name and the local shutter time.
3. Keep the originals of both. Copy them off the phone by cable or as an email attachment, not through a messaging app. Getting the original file intact is its own subject, and the same rules apply to your files as to a tenant’s.
4. If the date near a tenancy boundary matters, do not rely on the video’s timestamp. Use the stills’ capture times, which are local and are the moment each shutter fired. What a camera clock can and cannot show covers the rest.
5. Say the date and the unit out loud at the start of the video. It is not proof of anything on its own, but it is contemporaneous, it is in the footage, and it survives every re-encode the file will ever go through.

What our own tool does with a video, including what it did wrong until today

Our checker reads pictures. If you drop a video on it, nothing inside that file gets examined, and there is one right way to say so.

Until today it said it the wrong way. MP4 and MOV files begin with the same four bytes as a HEIC photo, so the page was classing a walkthrough video as an unreadable picture format and advising you to “export it as JPEG or PNG”. That is useless advice about a file we had never looked inside. It is fixed as of today: drop a video now and it says it is a video, that nothing in it has been checked, and — the part that matters — that this says nothing at all about whether it is real.

Two honest footnotes to that.

The Content Credentials standard does cover video; MP4 is in the specification alongside still images. So a video can carry signed provenance. Neither of the files we tested did. Since 18 September our page looks for them in an MP4 or MOV file, in the box the standard puts them in, and will say so if it finds one. We have tested that against a file we built to the specification, not yet against a signed video from a real camera or app.

Our free browser extension does make a call on videos, but only on the ones you scroll past on YouTube, TikTok, Instagram and Facebook, and what it produces there is a judgment about the picture, not evidence from the file. It is deliberately kept out of the paid report. A report that mixed the two would let a guess ride into a hearing wearing the same clothes as a fact, and this product will not do that.

The limits, stated plainly

• Two videos, one Android phone, one time zone. We have not tested an iPhone, and iOS writes its own QuickTime metadata keys that we did not examine. If you shoot on an iPhone, test yours before relying on any of the timing above.
• Some cameras write much more than this phone did, and location tagging is a setting, so yours may carry GPS where these did not.
• A creation time is a device’s clock. A wrong clock writes a wrong timestamp, and metadata can be edited afterwards.
• None of this detects AI. It is a description of what a file does and does not record. The report we file gives no confidence score, on video or on anything else.

Five minutes, your own phone

Shoot a ten-second video of the room you are in, then a still photo of the same room. Copy both to your computer by cable. Drop the still on the checker and read what comes back. Then check the video’s own properties and see how little is in there, and whether its timestamp is the second you pressed start or the second you pressed stop.

Whatever your phone does, you will know it before a deposit turns on it.

---

ImposterShield reads the evidence inside image files. It runs in your browser and uploads nothing. If a file has been stripped, it says so. That is the product working, not failing.