Two kinds of "timestamp" — and why the difference matters
Ask most people what a photo timestamp is and they picture the orange digits in the corner of a 1990s print — "1997 08 14" printed over a sunset. Ask a photographer and they will mention EXIF DateTimeOriginal, the invisible text tag every digital camera has written into its files since roughly 2000. These two things behave entirely differently, and the approach you need for one will not work for the other.
| Type | Source | How it is stored | Can it be fully erased? | Quality impact |
|---|---|---|---|---|
| Pixel-burned date stamp | Camera firmware (most DSLRs pre-2015, dedicated camcorders) or a third-party app | White or yellow digits baked directly into the image pixels | No — the pixels are modified; only crop, clone-stamp, or AI inpaint can hide it | Lossy — any repair alters surrounding pixels |
| EXIF DateTimeOriginal | Every digital camera and smartphone since ~2000 | Text tag in the file header, invisible to the eye | Yes — a metadata strip removes it without touching pixels | Lossless — image pixels are untouched |
What a pixel-burned date stamp actually is
From the mid-1980s through to roughly 2010, many consumer cameras — particularly 35mm film scanners, compact digitals, and camcorders — offered a "date imprint" feature. When enabled, the camera's firmware drew the date (and sometimes time) directly onto the image data before writing it to film or sensor storage. The result looks like white or orange digits in the bottom-right corner of the photo.
Because those digits are pixels, not metadata, there is no clean way to remove them. The background behind the numbers — the actual scene content — was overwritten at the moment of capture. What you are trying to recover does not exist in the file. Your options are:
- Crop — if the stamp is close to the edge, a tight crop removes it with no visible damage, though you lose a slice of the image.
- Clone stamp / healing brush — manually replace the stamped pixels with nearby texture. Works cleanly on uniform backgrounds (sky, wall, grass). Fails on complex texture (fabric, foliage, faces) because there is no reference for what was underneath.
- AI inpaint — modern tools like Adobe Firefly or DALL-E inpainting can generate plausible fill based on surrounding context. The result looks convincing on a quick glance but is synthesised — the "repaired" region never existed in the real scene.
Inpainting fails hardest when the stamp falls on a face, an eye, or a dense repeating pattern (tartan, brick). The model has no way to know what is under the digits, and the generated fill will be statistically plausible but not a faithful reconstruction. For archival, legal, or forensic use, that distinction matters.
Why pixel stamps can't be losslessly reversed
A JPEG stores each 8×8 block of pixels as frequency coefficients. When the camera firmware writes the date digits, it modifies specific blocks. Those blocks are then compressed with the rest of the image. The original coefficients for the scene content underneath are gone — replaced, not layered. Any decompression and repainting workflow introduces at least one JPEG re-encode, which adds generation loss on top of the already-modified blocks. Even if you use a lossless format like PNG as your intermediate, the pixel damage from the original burn is already present. There is no "undo layer" in a flat raster file.
The EXIF timestamp block — what it contains
The other kind of timestamp is entirely invisible and lives in the file header alongside lens and exposure data. Every smartphone and digital camera writes at least three date/time fields at capture. Here is what each one stores and why removing just one is often not enough.
| EXIF field | What is stored | Why it matters |
|---|---|---|
| DateTimeOriginal | The exact moment the shutter closed (YYYY:MM:DD HH:MM:SS) | Primary timestamp used by every photo manager and EXIF reader; reveals when the shot was taken |
| CreateDate (DateTimeDigitized) | Usually identical to DateTimeOriginal; may differ if the file was digitised from film | Second copy of the capture time — removing only one leaves the other behind |
| ModifyDate | Last time the file was written; updates when you resave or rotate | Can reveal post-processing dates even after scrubbing other fields |
| GPSDateStamp + GPSTimeStamp | UTC date and time from the GPS satellite signal, independent of camera clock | Often overlooked — a third copy of the capture time inside the GPS IFD block |
| SubSecTimeOriginal | Sub-second precision (milliseconds) appended to DateTimeOriginal | Narrows timing to under a second; useful for burst-shot identification |
Notice that GPSDateStamp and GPSTimeStamp are separate from DateTimeOriginal. They record UTC time from the GPS signal — often differing from the camera clock by a few seconds. Stripping DateTimeOriginal but leaving the GPS block intact means anyone reading the file still has a precise capture timestamp, just inside a different tag. The tool at the top of this page strips all metadata blocks in a single pass, so no orphaned date field remains.
Why removing timestamps is usually done alongside removing GPS
A date without a location is less useful for tracking than a date paired with a place. GPS coordinates tell an observer where the photo was taken; DateTimeOriginal tells them exactly when. Together they place a person or object at a specific spot at a specific moment — the same data combination that appears in surveillance logs, cell-tower records, and transactional databases.
For most privacy use cases — selling items second-hand, sharing portraits publicly, submitting images for a job application — stripping both time and location in one operation is simpler and safer than removing them piecemeal. The GPS removal page covers the coordinate fields in detail if you want GPS-only removal rather than a full metadata strip.
Platform-specific behaviour that brings timestamps back
Several platforms add their own temporal metadata on upload or re-export, which can confuse users who have already stripped the original EXIF.
- iOS Photos — when you export via "Save Image" from the share sheet, the OS writes a new DateTimeOriginal based on the capture date stored in the Photos library database, not the file header. Stripping the file and re-importing before export leaves the library metadata untouched.
- Android Gallery apps — Google Photos and Samsung Gallery both store capture time in their own databases. Exporting a "clean" file from these apps re-injects DateTimeOriginal from the database record. Export the file directly from a file manager bypassing the gallery app to avoid re-injection.
- Google Photos — photos uploaded before stripping are tagged with the original capture time in Google's servers. Downloading them later retrieves the database timestamp, not any stripped-file timestamp. The only fix is to delete the photo from Google Photos, strip the local file, and re-upload.
- WeChat export — when you forward a photo through WeChat and the recipient saves it, WeChat's compression pipeline strips most EXIF but writes a new DateTimeDigitized equal to the delivery time, not the capture time. The resulting timestamp is not the original one but is still a date.
- Screenshot workflow — taking a screenshot of a photo does create a new file with a fresh timestamp (the screenshot time, not the original capture). It also discards the original GPS coordinates. However, screenshots re-encode the image with visible quality loss, and they do not remove the visual pixel stamp if one is present in the original. A screenshot is not a substitute for a proper metadata strip.
Common mistakes when trying to remove date stamps
A few misunderstandings come up repeatedly, worth addressing directly.
Renaming the file does not help. The filename is a filesystem attribute, entirely separate from the image content or EXIF data. Changing "IMG_20221014_183022.jpg" to "untitled.jpg" leaves DateTimeOriginal, GPSDateStamp and every other metadata field completely intact. Any EXIF reader will still show the original capture time.
Screenshots remove EXIF but not pixel stamps. A screenshot re-encodes the visible image into a new file with no inherited EXIF block. So DateTimeOriginal disappears — but if the original photo had a burned-in date in the corner, the screenshot still shows those orange digits because they are part of the pixels. You lose image quality and still have the visible stamp.
Changing the file date in Finder or Explorer is not the same as editing EXIF. macOS and Windows let you change the filesystem timestamps (created date, modified date). Those are OS-level attributes attached to the directory entry, not EXIF fields. Any EXIF tool will still read the original DateTimeOriginal from inside the file.
Compressing or resizing in most apps preserves EXIF. Unless the tool explicitly strips metadata, resizing an image in Photoshop, Lightroom, or any standard image editor copies EXIF into the output file. The timestamp survives the resize intact.
Privacy cases where date stamps create real risk
The capture time in a photo is often overlooked relative to GPS data, but it carries its own risks depending on context.
Second-hand sales. A photo of items for sale taken at 6 AM can indicate a shift pattern. Photos taken consistently at the same time of day over multiple listings build a behavioural profile. Removing timestamps from sale listings is not paranoid — it is simply not providing information that has no relevance to the transaction.
Social media and journalism. Photos shared during a protest, a strike, or a sensitive meeting can be cross-referenced by timestamp across multiple uploads to establish timelines. Even if individuals strip their GPS data, a consistent 14:32 timestamp across twenty photos from different phones narrows a gathering to a six-minute window.
Legal and insurance contexts. Timestamps are used to establish alibis and to verify insurance claims. A photo taken three hours before a claimed incident is a different legal matter than one taken during it. Stripping timestamps before submitting documentation can raise questions about integrity — the appropriate step in legal contexts is to preserve original metadata and submit with provenance intact, not to strip it.
Identity documents and application photos. A headshot taken in 2019 used in a 2026 job application contains a DateTimeOriginal that contradicts the claimed currency of the image. Stripping metadata before submitting application materials is standard practice; the content of the image is what matters, not the capture metadata.
How to verify the EXIF timestamp is actually gone
After stripping, run the output file through the metadata viewer on this site. It reads the EXIF block inside your browser and lists every field present. If DateTimeOriginal, CreateDate and GPSDateStamp do not appear in the output, the strip was complete. If any date field remains, the tool you used preserved it — strip again with a different method.
The tool above uses the Canvas API to re-render the image without inheriting the original EXIF block. Processing runs entirely in your browser tab — no upload, no server, no copy of your file leaves your device. Check the Network panel in browser DevTools while processing: you will see no outbound image requests. Learn more about removing all metadata from a photo if you want to clear camera fields, software tags, and copyright notices alongside the date fields.
For command-line use, ExifTool gives precise control: exiftool -DateTimeOriginal= -CreateDate= -GPSDateStamp= -GPSTimeStamp= photo.jpg removes just the time fields. To strip everything in one pass: exiftool -all= photo.jpg. The metadata strip tool handles the browser-based equivalent without any software to install.