ByteScope

PowerPoint presentation (pptx) file format

A Microsoft PowerPoint presentation in the Office Open XML format.

MIME type
application/vnd.openxmlformats-officedocument.presentationml.presentation
Extensions
.pptx
Category
Documents

Magic-number signature

0x00000000504B0304PK··'PK' — it is a ZIP

Inside the ZIP: '[Content_Types].xml' plus a 'ppt/' directory.

About the PowerPoint presentation (pptx) format

A .pptx is an Open Packaging Conventions package: a ZIP whose parts describe slides, layouts and masters, plus the media they reference. ppt/presentation.xml names the slide order, each ppt/slides/slideN.xml holds one slide's shapes and text, and the pictures and video sit as ordinary files under ppt/media/. Because the media is stored rather than embedded in markup, a deck's size is almost entirely its images — which is why extracting the ZIP is the fastest way to pull every picture out of a presentation.

Header layout, byte by byte

OffsetLengthFieldMeaning
04Local file header signature50 4B 03 04 — the file is a ZIP, and at this offset it is indistinguishable from a Word document, a workbook, an e-book or a plain archive. The presentation-ness lives entirely in the entry names.
42Version needed to extractMinimum reader version times ten, little-endian. 20 for deflate. Decks with large embedded video are the one OOXML flavour that genuinely reaches the 4 GiB wall and needs 45 for ZIP64.
62General purpose bit flagBit 3 relocates the CRC and sizes to a data descriptor after the data, bit 11 declares the name UTF-8. Media filenames dragged in from a desktop are often non-ASCII, so bit 11 is set more often in a deck than in a document.
82Compression method8 for the XML parts. Media under ppt/media/ is frequently stored with method 0 instead, because deflating an already-compressed JPEG or MP4 costs time and gains nothing — so a big deck's ZIP is mostly stored bytes.
102Last modified timeMS-DOS packed time, two-second resolution, no time zone. PowerPoint normalises these; the meaningful authoring dates are in docProps/core.xml inside the package.
122Last modified dateMS-DOS packed date with the year counted from 1980, so nothing earlier can be expressed and old imported media lands on 1980-01-01.
144CRC-32Checksum over this part's uncompressed bytes only. A deck can fail on one damaged image while every slide's XML verifies perfectly, which is why a corrupt .pptx often opens with the text intact and one broken picture.
184Compressed sizeStored byte count of this part. For media entries stored with method 0 this equals the uncompressed size exactly — a quick way to spot which entries are raw media in a hex dump.
224Uncompressed sizeOriginal length. Compare the two size fields across the archive and the shape of a deck becomes obvious: a handful of highly compressible XML parts and a long tail of incompressible media.
262File name length13 00, nineteen bytes, when [Content_Types].xml leads the package as every OOXML writer arranges. The first informative field in the file.
282Extra field lengthZero from PowerPoint itself. Repacking tools add Unix permission and timestamp extra fields here, which alters the file's hash without changing a single slide.
3019First entry name[Content_Types].xml. Its Override for /ppt/presentation.xml carries a content type ending presentationml.presentation, which is the package's own declaration of what it is — more authoritative than any extension.
variablevariableppt/presentation.xmlThe part that makes the package a deck. Not at a fixed offset — reach it through the central directory. It lists slide ids in presentation order, each resolving through ppt/_rels/presentation.xml.rels to a ppt/slides/slideN.xml part, so the numeric part names do not have to match the running order.
-224End of central directory signature50 4B 05 06, twenty-two bytes from the end with an empty archive comment. A reader enumerates slides from here, so the tail of the file is what has to survive for the deck to open at all.
-64Offset of the central directoryAbsolute byte position of the directory, subject to the same caveat. Anything prepended to the file breaks it, and PowerPoint reports a corrupt presentation rather than attempting to correct the shift.

Telling it apart from its neighbours

Easily confused withHow to tell
Word document (docx)The same package format with a different payload, identical through the whole local file header and identical again at offset 30. The central directory settles it: ppt/presentation.xml and a ppt/ tree against word/document.xml and a word/ tree. The [Content_Types].xml part also states the flavour explicitly in its Override content types.
pptThe predecessor is a Compound File Binary container starting D0 CF 11 E0 A1 B1 1A E1, holding a stream literally named 'PowerPoint Document'. Both are called 'a PowerPoint file' and both open in the same application, but nothing about their internals is shared — the newer format is a ZIP of XML, the older is a mini filesystem of binary records.
ZIPIt is a ZIP, so the question is which one. The test has to be positive: [Content_Types].xml plus _rels/.rels at the package root make it OOXML, and a ppt/ directory makes it a presentation. A plain archive that happens to contain a folder called ppt is not a deck, because it will have neither required part.
pptmThe macro-enabled sibling, byte-identical everywhere a header inspection reaches. The difference is a ppt/vbaProject.bin part and a different declared content type. Because renaming .pptm to .pptx changes nothing structurally, only opening the package resolves which one you have.

How these files break

  • The archive's tail was lost. Slides remain fully compressed and intact in the file while PowerPoint refuses to open it, because slide enumeration begins at the end-of-central-directory record. Scanning forward for 50 4B 03 04 and rebuilding the directory typically recovers every slide and every image.
  • Bytes prepended before 50 4B 03 04. A download that captured an error page first shifts the whole package, so the central directory's absolute offsets no longer land on real headers. Every slide is still present; removing the leading bytes restores the deck.
  • Text-mode transfer. Line-ending translation corrupts the deflate streams while leaving every header field and entry name legible, so the package lists correctly and fails on a CRC mismatch as a slide inflates. Media stored with method 0 gets corrupted just as silently and shows up as a broken image rather than an error.
  • A single damaged media entry. Because pictures and video are ordinary ZIP entries, one bad image leaves all slide XML verifying and simply renders as a missing-picture placeholder on one slide. This is the most common real-world .pptx failure and it is entirely local to one entry.
  • Repacked with the wrong layout. Editing a slide's XML by hand and re-zipping is easy to get wrong: including directory entries for the folders, changing name case, or introducing a BOM before the XML declaration each produce a package that every ZIP tool calls healthy and PowerPoint calls corrupt.

Where the format stands today

The .pptx package is the default presentation format and it is not under any real pressure, because presentations are one of the few document types with no serious alternative standard — Keynote and Google Slides both import and export it rather than trying to displace it. As a container it is a good design: an open ISO standard, media stored as ordinary files so extraction is trivial, and XML parts that make a damaged deck largely recoverable. Its practical problems are all about size and fidelity. Because media is embedded rather than referenced, a deck with a dozen full-resolution photographs and a video is hundreds of megabytes and gets mailed around as-is; and because rendering depends on fonts, layouts and inherited masters, a deck opened on a machine missing its typefaces reflows in ways that shift every text box. That last problem is exactly why the final version of a deck is so often exported to PDF before it is sent — the editable format for building it, a fixed-layout format for delivering it. For extracting assets from someone else's presentation, treating it as what it is — a ZIP — is faster and lossless compared with saving images out one by one.

Open PowerPoint presentation (pptx) files on this site

Every one of these runs in your browser — the file never leaves your machine.

Related formats

Formats that are easy to confuse with PowerPoint presentation (pptx) — compare their leading bytes.

FormatFirst bytesExtension
Word document (docx)50 4B 03 04.docx
Excel workbook (xlsx)50 4B 03 04.xlsx
ZIP50 4B 03 04.zip
OLE2 / CFBD0 CF 11 E0 A1 B1.doc

Frequently asked questions

What is a magic number in a file?

The first few bytes of a file, which identify its format regardless of what the name says. A PNG always starts with 89 50 4E 47; a ZIP with 50 4B 03 04. Operating systems, browsers and the file command all read these bytes rather than trusting the extension, which is why renaming a file does not change what it actually is.

How do I check a file's magic number myself?

On macOS or Linux, xxd -l 16 yourfile prints the first 16 bytes; on Windows, Format-Hex -Path yourfile -Count 16 in PowerShell. Or drop the file into the File Type Identifier on this site, which reads the bytes locally and names the format for you — nothing is uploaded.

Why do two formats share the same magic number?

Because one is built on the other. Every docx, xlsx, pptx, apk, jar and epub begins with the ZIP signature, since all of them are ZIP archives underneath; telling them apart means looking at the entries inside. Java class files and macOS universal binaries both start with CA FE BA BE and are distinguished by the field that follows.

Can a file have no magic number at all?

Yes. Text-based formats — XML, HTML, JSON, SVG, CSV — have no fixed byte signature, so they are recognized structurally instead: a leading <?xml declaration, a <svg element, or a { followed by a quoted key. That detection is a good guess rather than a certainty, which is why this reference marks those formats as probe-detected.

Does a matching magic number mean the file is safe?

No. It tells you what the format is, not whether the contents are harmless — a genuine PDF or docx can still carry a malicious payload. Identifying the true type is a useful first check, especially when the extension disagrees with the bytes, but it is not a malware scan.

Have a file that might be in the PowerPoint presentation (pptx) format? Identify it with the File Type Identifier — it reads the magic number locally, nothing is uploaded. Or browse all formats.