How to Prove When a File Was Created or Modified

The question of when a file was created or modified comes up in situations where the timing actually matters, and the answer is rarely as simple as looking at the date shown in a file explorer. Operating systems display timestamps that can be changed with a few clicks, copied with a file, or reset when a drive is formatted, so a displayed date is a clue, not proof. What you can prove technically is a set of facts about the file as it exists now: what metadata is embedded inside the file itself, what cryptographic fingerprint it has, and what timestamps are recorded by the system that stored it. Those facts do not by themselves establish legal ownership or intent, they document the technical evidence that can be used to support a claim about creation or modification. In practice, proving a timeline means combining several independent layers of evidence and recording them in a way that is reproducible. The first layer is the file system metadata that the operating system maintains. The second layer is the internal metadata written by the application that created the file. The third layer is the cryptographic hash that uniquely identifies the file’s current bytes. When those three layers are captured together, with a contemporaneous report, you have a much stronger technical foundation than any single date shown in Explorer or Finder.

File system timestamps are the most familiar reference point, and also the most fragile. On Windows you typically see Created, Modified, and Accessed. Created is the date the file entry was first written to that particular volume, Modified is updated when the file contents change, and Accessed is updated when the file is read. On macOS and Linux you also have Change, which updates when metadata changes. None of these timestamps are cryptographically protected. They travel with the file when it is copied, they can be altered with tools like touch or PowerShell, and they are reset when a file is moved between file systems or restored from a backup. Cloud sync services and version control can also rewrite them without touching content. That is why forensic analysts treat file system dates as contextual information rather than definitive proof. They are useful for building a narrative, for example showing that a photo appeared in a folder after a specific event, but they cannot on their own prove when the image was actually taken or when the document was first authored. The real value comes from comparing system timestamps with internal timestamps and with hashes taken at different points in time.

Internal metadata is often far more informative because it is written by the creating application and travels inside the file. Images contain EXIF, XMP and IPTC blocks that can record the camera make and model, lens, exposure settings, and a DateTimeOriginal tag that reflects when the shutter was triggered. Video files carry container metadata such as creation_time in MP4 or MOV atoms, and audio files can hold tags written by encoders. Documents are especially rich. A PDF can store Producer, Creator, CreationDate and ModDate in the document info dictionary, and many PDFs also contain an incremental update history that shows later edits. A DOCX file is a ZIP package with XML parts that include core properties for created and modified dates, and often the author name and revision history. CAD files like DWG and STEP store application-specific timestamps and user information. Because this metadata lives inside the file, it survives copying and is harder to change without leaving traces, though it can still be edited by knowledgeable users. Reading it correctly requires a parser that understands the format, which is why generic tools often miss fields or misinterpret time zones. A comprehensive view of what a format can contain is available in the full list of supported formats and the format-specific guides that explain where dates are typically stored.

Cryptographic hashing provides the only reliable way to prove that a file has not changed between two points in time. A hash such as SHA-256 is a deterministic fingerprint of the file’s bytes. If even a single bit changes, the hash changes completely. That property makes hashes ideal for integrity verification and for documenting a file at a specific moment. You can record a hash today and compare it later; a match means the file is bit-for-bit identical, a mismatch means it has been altered. Hashes do not tell you when the file was first created, but they do let you prove that the file you are examining now is the same file you saw yesterday, last week, or at the time of an incident. When paired with a timestamped report, a hash creates a verifiable anchor. For example, a journalist receiving a leaked document can immediately compute its SHA-256, store it, and later demonstrate that the version published is identical to the original received version. The same principle applies to software verification, where developers publish hashes for releases so users can confirm downloads have not been tampered with. Hashes are also the basis for duplicate detection, because two files with the same hash are guaranteed to be identical.

This is where a systematic extraction and reporting workflow becomes practical. Rather than manually checking properties dialogs and running command-line hash utilities, a forensic-focused tool can extract file system timestamps, parse internal metadata, compute multiple hashes, and bundle everything into a timestamped PDF report. FilesAudit is designed for exactly this kind of documentation, extracting technical metadata, computing SHA-256, MD5 and CRC32, and producing a professional report that records when the analysis was performed. The platform does not determine legal authenticity on its own, it documents the technical evidence that supports a timeline claim. It supports 200 plus formats across images, video, audio, documents, archives, CAD 3D, source code and more, so you can compare the dates reported by the operating system with dates embedded by the camera, encoder or authoring application. Using a consistent process means you can repeat the analysis later and show that the results are reproducible. For deeper context on specific file types you can consult dedicated guides such as the metadata guide for PDF files or the guide for MP4 files.

Practical examples make the layers clear. A photographer handing over a JPEG for a news story might point to the file explorer date, but a stronger technical statement combines the EXIF DateTimeOriginal, the file system Modified date, and a SHA-256 hash recorded at receipt. If the EXIF date predates the story event and the hash matches the published image, you have a coherent technical picture. A lawyer reviewing a contract can check the PDF’s internal CreationDate and ModDate, look for incremental updates that indicate post-signature edits, and verify the hash against a copy stored at signing. The related article How to See Who Created a Word Document explains how DOCX core properties and revision metadata can reveal author names and last saved times that are not visible in Word’s UI. A developer investigating a bug report can hash a build artifact, compare it with the hash logged in CI, and then inspect the archive metadata to see when the package was assembled. In each case the goal is not a single date, it is a set of corroborating technical facts captured together.

There are important limits to what technical evidence can say. Metadata can be missing, stripped by editors, or deliberately falsified. Time zones are often not recorded consistently, so a timestamp may need conversion and contextual interpretation. File system dates can be spoofed, and some applications allow users to edit EXIF or document