- Nationwide Digital Forensic & Cyber Investigation Services
Read core.xml, app.xml and custom.xml as stored claims about a presentation, then compare those claims with independently dated copies and actual package contents.
Home › Digital Evidence Authentication › PowerPoint Presentation Authentication › PPTX Metadata and Document Properties
Quick Answer. PPTX metadata includes core author and date fields, extended application properties, optional custom properties and sometimes a saved thumbnail. These values help test a presentation history, but most are editable or inherited. Examiners compare them with email originals, file system context, cloud versions and content differences rather than treating any single timestamp or author name as proof.
This guide is part of PowerPoint Presentation Authentication. Read it alongside presentation structure and content analysis and timeline and authenticity testing. The focus here is pptx metadata and document properties, with a clear separation between observed file facts and conclusions that require independent corroboration.
| Question | Short answer |
|---|---|
| Where are PPTX author and modified properties stored? | Usually in docProps/core.xml, including dc:creator, cp:lastModifiedBy and dcterms:modified. |
| What does PPTX app.xml TotalTime mean? | It is an application maintained editing duration, conventionally expressed in minutes. It is not a record of individual editing sessions. |
| Can PPTX Slides and HiddenSlides counts be stale? | Yes. Compare application summary fields with the actual ordered slides and their visibility attributes. |
| Does PPTX metadata identify a human author? | A creator value identifies a stored name. Corroborating account and source records are needed to associate that name with a person. |
| What can PPTX TitlesOfParts reveal? | It can retain descriptive part titles supplied by the producer. Compare it with the current presentation rather than assuming it is authoritative. |
| Is docProps/thumbnail.jpeg reliable PPTX history? | It is a saved preview that may differ from current content. It supplies a comparison lead, not an independent date. |
Shared Open XML properties such as creator, modified date and revision, usually stored in docProps/core.xml.
Application and content summary fields usually stored in docProps/app.xml, with producer dependent update behavior.
Optional typed name and value pairs defined by a user or application in docProps/custom.xml.
Coordinated Universal Time, commonly indicated by Z in a timestamp. A timestamp label does not make the source clock trustworthy.
An optional thumbnail image stored with a deck, potentially reflecting an earlier saved visual state.
A record outside the deck, such as a provider version event or email receipt, that can corroborate a particular timeline claim.
Extract properties from the preserved package rather than relying only on a user interface, which may rename fields, localize times or hide values. Preserve exact strings and distinguish a missing field from an empty field. The application that last saved the package may not be the application that created the original slides.
| Part and fields | Typical meaning | Forensic caution |
|---|---|---|
| core.xml: creator and lastModifiedBy | Attributed creator and most recent saving identity | Editable names can be inherited from templates or shared accounts |
| core.xml: revision | Producer maintained revision value | Not a dependable edit count or complete revision history |
| core.xml: created and modified | Claimed creation and modification times, commonly in UTC | Can be altered, preserved during conversion or affected by clock errors |
| app.xml: Application and AppVersion | Reported producer and application version | Need controlled comparisons and a plausible software timeline |
| app.xml: TotalTime | Accumulated editing time value, commonly minutes | Not an authenticated measure of labor or active editing |
| app.xml: Words and Paragraphs | Stored text summary counts | May be stale or calculated differently by another producer |
| app.xml: Slides, Notes and HiddenSlides | Stored presentation content counts | Compare with actual referenced parts and hidden states |
| app.xml: MMClips | Stored multimedia summary count | Not a complete inventory of every media package part |
| app.xml: PresentationFormat and Company | Presentation format label and organization value | Can be generic, user supplied or inherited |
| app.xml: HeadingPairs and TitlesOfParts | Grouped lists that may include fonts, theme names and slide titles | Entries depend on producer and save behavior, not a complete design history |
| docProps/thumbnail.jpeg | Optional saved image preview | May show an earlier first slide or be absent |
| custom.xml | User or application defined typed properties | A named approval field is not a verified approval event |
Summary counts do not substitute for examining referenced slides and their contents. An orphaned slide part can be present without belonging to the active slide sequence. A font listed in extended properties may not be used by a visible text run. Resolve the actual XML parts and theme dependencies before reporting a contradiction.
In docProps/app.xml, record Slides, Notes, HiddenSlides, MMClips, TotalTime and TitlesOfParts independently. A deck with 12 slide references and one p:sld show="0" should be compared with its reported counts; disagreement is a finding, not permission to rewrite the source. TitlesOfParts can include titles whose wording differs from the current slide objects. Extract docProps/thumbnail.jpeg when present and compare its visible wording with the current first slide. Preserve the thumbnail bytes and dimensions as well as a viewing derivative.
Provide the deck together with the dated message or repository version. We can compare the property claims with the preserved event rather than treating a modified field as its own corroboration.
Request Confidential Consultation Call (833) 292 3733A deck can carry several valid dates describing different events. File system creation may mean arrival on a particular volume, while a core created value may have survived years of editing. An email receipt can establish that an attachment was received by a system, not when every slide originated. Record the event each timestamp actually represents.
| Time source | Event it may describe | Limit and useful comparison |
|---|---|---|
| Core created or modified | Application supplied document lifecycle claim | Compare with known copies and relevant device clock context |
| File system creation or modification | Storage and write events on a particular system | Copying, synchronization and extraction can change these values |
| ZIP entry timestamps | Archive member times supplied during packaging | Not a reliable slide creation chronology or trusted UTC record |
| Email server and attachment records | Transmission or receipt of a message carrying content | Preserve full message and attachment bytes, not a forwarded screenshot |
| Cloud version history | Provider recorded file version and account activity | Collect version bytes, identifiers and event semantics |
| Embedded asset metadata | Lifecycle information for an image, recording or workbook | Does not independently establish insertion time in this deck |
Normalize times to a stated reference zone while retaining original values and precision. Explain daylight saving conversion, missing offsets and clock uncertainty. A difference of hours can be a zone issue; a later embedded asset might reflect a later legitimate update. Neither observation should be silently forced into a single narrative.
Suppose a presentation is described as an unchanged attachment from an earlier transaction, but its current application version indicates a later save. That establishes a reason to examine the original message, not an automatic conclusion that its business content was fabricated. A current application can open and save older material while retaining the original created value.
Compare the saved thumbnail with a controlled rendering of the current first slide. Differences may reflect a changed title, a changed logo or a stale preview. Document both images and the software used to render the slide. A thumbnail is a small representation and may not resolve wording clearly enough to support a precise textual comparison.
AppVersion is a producer claim, not a signed software attestation. Versions and product releases do not always map neatly to one date, especially across channels and platforms. Use reliable release documentation and controlled sample files. Report a demonstrable incompatibility with a claimed save date more narrowly than a conclusion about the age of the slide ideas.
A slide deck may reuse descriptions from a Word file or figures from a spreadsheet. Compare those sources where authorized rather than attributing every inconsistent property to the presentation editor. The Word authentication guide and Excel authentication guide describe related metadata limits. The presentation authenticity checklist explains how these observations fit a broader timeline.
Transcribe raw values before normalization. Preserve absence, malformed values and differing timestamp precision instead of silently replacing them.
We audit presentation properties against the actual package and event anchored comparison files. Reports distinguish raw stored values, normalized time representations and independently supported historical facts. Our examiners are subject matter experts in PPTX metadata analysis and compare presentation properties with file system, email, and meeting records.
Elite Digital Forensics is an independent digital forensics practice serving attorneys, paralegals, in house counsel, insurers, lenders, businesses, and individuals nationwide. Our team includes former law enforcement forensic examiners and court qualified expert witnesses in computer, cell phone, cloud, document, and multimedia forensics. Every engagement begins with a scoped plan, hash verified evidence handling, and a clear explanation of what the examination can answer.
Yes. A save under another user profile can update properties even when the disputed wording is unchanged. Compare substantive content separately.
Z denotes UTC. Preserve the original value and state any local reporting zone, including the applicable offset for that date.
It is a producer supplied multimedia summary. Enumerate actual audio and video relationships before drawing conclusions from the number.
Yes. They may contain matter names, project codes or user defined dates. Record their types and values, then seek independent records that explain their use.
No. It describes a stored producer version value that may reflect a later save. Compare it with package features and earlier copies.
The inconsistency is an observation to explain. Repairing or normalizing the source can erase evidence of conversion, reuse or a later save.
Keep original values, actual part counts and external events side by side. This makes the timeline auditable and prevents an editable field from becoming an unsupported historical conclusion. As court qualified experts in document metadata, we can explain author and date conflicts in plain language.
Request Confidential Consultation Call (833) 292 3733This content is for educational and informational purposes only and does not constitute legal advice. Elite Digital Forensics provides independent digital forensic services and expert witness testimony; we do not provide legal representation. Every case is fact specific; outcomes depend on the evidence, jurisdiction, and counsel. Retain qualified legal counsel for advice about your matter.
Elite Digital Forensics Assistant
By submitting this form, you consent to be contacted by email, text, or phone. Your information is kept secure and confidential. Reply Stop to opt out at anytime.
IMPORTANT: Please remember to check your spam or junk folder