Do Screenshots Have Timestamps? Three Places a Time Can Hide
Short answer: a screenshot usually has a timestamp, but almost never inside the image. We opened 151 real Windows screenshots and walked every PNG chunk — zero of them contained a tIME block. The time you see lives in two places outside the pixels: the filename (all 151 files were named with a date and time, e.g. “屏幕截图 2026-09-15 153403.png”) and the filesystem (mtime matched the filename to the second). A third possible place — the PNG tIME chunk — exists in the spec but not in these files, and even when present it means “last modified”, not “captured”. None of the three is evidence of when the screen was actually photographed. For what is in a screenshot, see our main guide, do screenshots have exif data.
How we tested it (real files, not a guess)
We did not paraphrase a blog post. We ran a chunk walker over real files on a Windows machine, using Pillow 12.3.0 and Python 3.13.
1. 151 real screenshots. Every PNG in the Windows Snipping Tool output folder (C:\Users\<user>\Pictures\Screenshots), captured between 2026-09-15 15:34:03 and 2026-10-05 19:33:19. For each file we read the 8-byte PNG signature, then looped over 4-byte length + 4-byte type + payload + 4-byte CRC, and recorded every chunk type and size.
2. A control PNG. A flat 1280×720 RGB image written by Pillow’s default encoder, to see what a bare PNG contains.
3. A tIME injection test. We hand-built a tIME chunk (7-byte payload, big-endian, plus CRC32), inserted it directly after IHDR, and read it back — to prove what the block looks like when it is there, and how many bytes it costs.
4. A mutability test. We copied a screenshot two ways (shutil.copy2, which preserves mtime, and shutil.copyfile, which does not), then rewrote mtime with os.utime, checking after each step whether the file bytes had changed.
Everything below is a number we read off a file in this session. Nothing is estimated.
The three places a timestamp can hide in a screenshot
When people ask “does a screenshot have a timestamp”, they usually mean one of three very different things. Only one of them is image data.
| Where | What it records | Travels with the file? | Can it be changed? |
|---|---|---|---|
| Filename | The moment the capture tool named the file (a naming convention, not a data field). | Yes — it is the file’s name. | Yes, trivially — rename the file. |
| Filesystem (mtime / ctime / atime) | When the file was last written, when its metadata last changed, when it was last opened. | No — it is stored by the OS, not in the file. | Yes — a plain copy resets it; utime rewrites it. |
PNG tIME chunk | Per the spec, the time of the last image modification — not creation. | Yes — it is inside the PNG byte stream. | Yes — it is just bytes; anything that rewrites the file can rewrite it. |
The important asymmetry: the first two live outside the image bytes. Re-encode the picture, and they are gone. The third lives inside, but in our 151-file sample it was not there at all.
What 151 real screenshots actually showed
This is the part we could not have guessed. Across 151 files written by the Windows Snipping Tool:
| Measurement | Result |
|---|---|
| Files examined | 151 |
Files containing a tIME chunk | 0 (0.0%) |
| Files whose name contains a date and time | 151 (100%) — format “屏幕截图 YYYY-MM-DD HHMMSS.png” |
| Files where filesystem mtime matched the filename time to the second | 151 (100%) |
| Chunk types found across all 151 files | IHDR (151), sRGB (151), gAMA (151), pHYs (151), IDAT (266 total), IEND (151). No tEXt, no tIME, no eXIf. |
One concrete file: 屏幕截图 2026-09-15 153403.png, 173,483 bytes. Its chunks were IHDR(13), sRGB(1), gAMA(4), pHYs(9), three IDAT blocks, IEND(0) — and no tIME. Its mtime read 2026-09-15 15:34:03, exactly the 153403 in the name.
So the timestamp the user “sees” in Explorer is produced twice, independently: once by the capture tool when it builds the filename, and once by the filesystem when it closes the file. The PNG itself is silent about time.
Why the tIME chunk is absent — and what it means when present
The PNG specification does define a time block. From the W3C PNG (Third Edition) spec, section 11.3.5.1:
“The
tIMEchunk gives the time of the last image modification (not the time of initial image creation). It contains: Year 2 bytes … Month 1 byte (1-12) … Second 1 byte (0-60) (to allow for leap seconds). Universal Time (UTC) should be specified rather than local time.”
Three things follow, and they are the reason this chunk is a bad place to look for “when was this screenshot taken”:
1. It is not a creation time. By definition it records the last modification. Any tool that re-saves the image is entitled to bump it. It answers “when was this file last touched”, not “when was the screen captured”.
2. It is UTC. If a writer does fill it in, the value is UTC, not your local clock. A screenshot taken at 15:34 in UTC+8 should read 07:34 in the chunk. Reading it as local time gives a silent 8-hour error.
3. It is optional, and screenshot tools skip it. tIME is an ancillary chunk. Nothing breaks if it is missing — and in all 151 real screenshots we opened, it was missing. Our Pillow control PNG had only three chunks (IHDR, IDAT, IEND), also with no tIME.
For completeness, we injected one by hand. A 7-byte payload plus the standard 12 bytes of length/type/CRC cost 19 bytes: the file went from 4,321 to 4,340 bytes, the chunk read back as 2026-10-27 09:14:33, and the decoded pixels were identical. That is the whole footprint of a timestamp inside a PNG — 19 bytes that most capture tools never write.
Can the timestamp be changed? Yes — and the pixels never move
We took one real screenshot (mtime 2026-09-15 15:34:03) and copied it two ways. The file bytes were identical every time; only the timestamps moved.
| Operation | mtime | ctime | Bytes changed? |
|---|---|---|---|
| Original file | 2026-09-15 15:34:03 | 2026-09-15 15:34:03 | — |
shutil.copy2 (preserves mtime) | 2026-09-15 15:34:03 (kept) | 2026-10-27 12:57:16 (reset) | No |
shutil.copyfile (plain copy) | 2026-10-27 12:57:16 | 2026-10-27 12:57:16 | No |
os.utime to a chosen date | 2020-01-01 00:00:00 | 2026-10-27 12:57:16 | No |
Read that last column again. The PNG was byte-for-byte identical in every row — we checked with a direct byte comparison — yet the visible “date” moved by six years. A timestamp that can be rewritten without touching a single pixel is a filesystem attribute, not image evidence.
This is also why the filename is weak evidence: renaming is a one-second operation that leaves no trace in the file content. The name is a label, not a record.
What this means for privacy — and for proving when a screenshot was taken
For privacy, the news is mostly good. A screenshot does not carry a camera capture time, and in our sample it did not carry a PNG time block either. The time is in the filename and the filesystem, both of which live outside the pixels. If you rename the file and re-save or re-encode it, the timestamp does not travel with the image.
But “no timestamp in the file” is not the same as “no way to know when it happened”:
1. Platforms record upload time. The moment you post the image, the service timestamps the upload server-side. That record is not in your file and you cannot edit it.
2. The content itself leaks time. A clock in the taskbar, a “3 minutes ago” label in a chat window, a dated email in the frame — all of it is pixels now. That is the part a metadata stripper cannot help with, which is the same boundary we drew in our test of whether a screenshot of a photo keeps EXIF.
3. Timestamps are not proof. Because mtime and the filename can both be rewritten without changing one byte of image data, neither can establish that a screenshot was taken at a claimed moment. If you need that, you need an external record — a signed capture, a server log, a chain of custody — not a file property.
If you want to know which container blocks are present, our chunk-by-chunk inventory is in what metadata do screenshots have. If you want the short answer to the EXIF question, it is in do screenshots have exif data.
FAQ
Do screenshots have timestamps? Usually yes, but outside the image. In 151 real Windows screenshots, every filename contained a date and time and every filesystem mtime matched it; none of the PNG files contained a tIME chunk.
Is there a timestamp inside a PNG screenshot? Only if the writer added a tIME chunk, which is optional. Zero of our 151 real screenshots had one. Our Pillow-written control PNG had three chunks (IHDR, IDAT, IEND) and no tIME either.
What does the PNG tIME chunk actually store? The time of the last image modification, in UTC, as 7 bytes: year (2), month, day, hour, minute, second (1 each). The W3C spec explicitly says it is not the creation time.
Why does the tIME chunk read 8 hours off? Because it is UTC. A screenshot taken at 15:34 local time in UTC+8 is written as 07:34 if a writer fills it in at all.
Can I remove the timestamp from a screenshot? You can rename the file and re-save or re-encode the image, which drops the filename time and resets the filesystem time. Removing an in-file tIME chunk is a 19-byte surgical edit — we injected and removed one in this test. You cannot remove a platform’s server-side upload record.
Does a timestamp prove when a screenshot was taken? No. mtime and the filename can both be rewritten while the PNG stays byte-identical — we moved one file’s mtime to 2020-01-01 without changing a single byte of image data. Treat timestamps as hints, not evidence.
Related reading
If you are working through the metadata question on screenshots, these are the next reads:
- Do screenshots have EXIF data? — the main guide: what a screenshot does and does not carry.
- What metadata do screenshots have? — every PNG chunk, enumerated on real files.
- Does a screenshot of a photo keep EXIF? — what happens to GPS and camera tags when you screenshot a photo.
- Do iPhone screenshots have EXIF? — the same question on iOS, where the file format differs.