EPUB File Documentation

Summary

An EPUB (Electronic Publication) file is the standard open e-book format: reflowable XHTML and CSS content packed inside a ZIP container. Its MIME type is application/epub+zip and a .epub opens in Calibre, Thorium Reader, Apple Books or Google Play Books. Since late 2022, Kindle accepts EPUB directly through Send to Kindle, so the old “convert to MOBI” step is no longer needed. Text reflows to any screen, unlike a fixed-page PDF.

Technical details

FeatureValue
Full nameElectronic Publication (EPUB)
File extension.epub
MIME typeapplication/epub+zip
Format typeZIP-based e-book container (XHTML/CSS content, XML metadata)
DeveloperW3C (originally IDPF; merged into W3C in February 2017)
Introduced2007 (EPUB 2.0, IDPF)
Latest versionEPUB 3.3 — W3C Recommendation, 25 May 2023
SpecificationW3C EPUB 3.3
Open standardYes
Container / base formatZIP (OCF — Open Container Format)
Magic number50 4B 03 04 (ZIP), then mimetype entry at offset 30
Content documentsXHTML5, styled with CSS
Package document.opf (metadata, manifest, spine)
NavigationEPUB 3 nav document (XHTML); legacy toc.ncx for EPUB 2
MultimediaAudio, video, MathML, SVG, scripting, Media Overlays
Fixed layoutSupported (EPUB 3)
Font embeddingAllowed (may be obfuscated per the OCF spec)
InternationalisationMultilingual, right-to-left, vertical writing
DRM optionsAdobe ADEPT, Readium LCP, Apple/Kobo DRM (all optional)
Related extensions.mobi, .azw3, .kfx, .fb2, .pdf, .kepub
Specification URLw3.org/TR/epub-33/
File signature (magic bytes)
50 4B 03 04

Offset 0, 4 bytes: PK\x03\x04, the ZIP local file header — an EPUB is a ZIP archive. The reliable secondary check is the first archive entry, which the specification requires to be an uncompressed file named mimetype containing exactly application/epub+zip. Because that entry is stored (not deflated), the ASCII string mimetypeapplication/epub+zip appears at byte offset 30, which is how readers tell an EPUB from a plain .zip.

What is an EPUB file?

EPUB stands for Electronic Publication. It is the dominant open standard for e-books: a complete book (text, styling, images, fonts and metadata) packaged into a single ZIP archive with a mandated internal layout. The International Digital Publishing Forum (IDPF) released EPUB 2.0 in 2007 as the successor to the earlier Open eBook (OEB) publication structure. The IDPF merged into the W3C in February 2017, and the current version, EPUB 3.3, became a W3C Recommendation on 25 May 2023. Its MIME type is application/epub+zip.

The defining property is that EPUB is reflowable. Unlike a PDF, which freezes content onto fixed pages, an EPUB stores its text as XHTML styled with CSS, so a reader can re-lay it out for any screen size and font size, the way a web browser reflows a page. Everything below is about how the container is built and how a reading system turns that ZIP into a book: the OCF layout, the mimetype rule, the OPF package document with its manifest and spine, the navigation document, and the DRM structures that stop generic readers from opening store and library books.

The OCF container and the mimetype rule

An EPUB is physically an Open Container Format (OCF) archive, which is an ordinary ZIP with two strict requirements. First, the very first entry in the archive must be a file named mimetype whose contents are exactly the ASCII string application/epub+zip, with no leading whitespace and no trailing newline. Second, that mimetype entry must be stored uncompressed and must not have an extra field in its local header.

ZIP local header of the first entry
  50 4B 03 04            "PK\x03\x04"  local file header signature
  ...                    method = 0 (stored, not deflated)
  offset 30:  "mimetype"              8-byte file name
  offset 38:  "application/epub+zip"  20-byte content, uncompressed

Because the file is stored rather than deflated, its bytes sit in a predictable place: the literal string mimetypeapplication/epub+zip begins at byte offset 30 of the archive. A reading system can therefore sniff those bytes and confirm it is holding an EPUB, not a random ZIP, before it inflates anything. Rename any .epub to .zip and a normal archive tool will list the chapters, images and metadata inside; the mimetype convention is the only thing that distinguishes the two.

META-INF and container.xml: finding the package

The archive has one mandatory directory, META-INF, and its required file is container.xml. A reading system opens this file first (after checking the mimetype) because it is the single fixed entry point: it names where the real package document lives. The path to the .opf is not fixed by the spec, so this indirection is how the reader finds it.

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
  <rootfiles>
    <rootfile full-path="EPUB/content.opf"
              media-type="application/oebps-package+xml"/>
  </rootfiles>
</container>

The rootfile element’s full-path attribute points at the OPF package document (here EPUB/content.opf, though publishers also use OEBPS/ or the archive root). META-INF can hold other optional files too: encryption.xml for DRM and font obfuscation, signatures.xml for digital signatures, and metadata.xml. Everything a reader does after this point starts from the OPF the rootfile named.

The OPF package document: metadata, manifest and spine

The .opf package document is the heart of an EPUB. It is an XML file in the http://www.idpf.org/2007/opf namespace with three parts that a reading system needs: what the book is (metadata), what files it contains (manifest), and the order to read them in (spine).

<package xmlns="http://www.idpf.org/2007/opf" version="3.0"
         unique-identifier="book-id">
  <metadata>
    <dc:identifier id="book-id">urn:isbn:9780000000000</dc:identifier>
    <dc:title>Example Book</dc:title>
    <dc:language>en</dc:language>
  </metadata>
  <manifest>
    <item id="nav"  href="nav.xhtml" media-type="application/xhtml+xml"
          properties="nav"/>
    <item id="c1"   href="chapter1.xhtml" media-type="application/xhtml+xml"/>
    <item id="css"  href="style.css" media-type="text/css"/>
  </manifest>
  <spine>
    <itemref idref="c1"/>
  </spine>
</package>

The <metadata> block uses Dublin Core elements (dc:title, dc:creator, dc:language, dc:identifier) plus EPUB-specific <meta> refinements. The <manifest> must list every resource in the publication (each XHTML chapter, stylesheet, font and image) with a unique id, its href and its media-type; a resource not in the manifest is not part of the book. The properties attribute flags special items, such as nav for the navigation document or cover-image for the cover. The <spine> then gives the default reading order as a list of itemref elements pointing at manifest ids; this, not the file names or the ZIP order, is what determines which chapter follows which.

Content documents, CSS and the reflow model

The actual book text is a set of XHTML content documents, conventionally one file per chapter, written as well-formed XHTML5. They are styled with CSS, and because they are standard web documents the reading system lays them out with a browser-style engine and reflows them to the viewport. This is the mechanism behind adjustable fonts, margins and themes: the reader overrides or supplements the publisher’s CSS at display time.

EPUB 3 widened what those documents may contain: MathML for equations, inline and referenced SVG, audio and video via HTML5 media elements, and Media Overlays (SMIL files that synchronise a pre-recorded narration with the text for read-aloud). EPUB 3 content may also carry JavaScript, which is powerful for interactive textbooks but is the reason readers sandbox scripting. Publishers who need pixel-exact pages (children’s books, comics, cookbooks) use the optional fixed-layout mode, which pins each XHTML page to a set viewport size instead of reflowing it.

The navigation document and the NCX legacy

Every EPUB 3 has a navigation document: an XHTML file flagged with properties="nav" in the manifest, containing a <nav> element with the table of contents as an ordinary nested list of links. Because it is XHTML, the same file can double as an in-book contents page. A machine-readable table of contents matters for accessibility: it lets a screen reader or a “jump to chapter” control move through the book by structure rather than by scrolling.

For backward compatibility with EPUB 2 reading systems, many files still include a legacy toc.ncx file (the “Navigation Control file for XML”, a holdover from the Digital Talking Book standard). EPUB 3 marks it as superseded, but shipping both the nav document and an NCX is common so that an older device still shows a working table of contents. This accessibility focus is not incidental: EPUB is the format underpinning publishing’s compliance with the EU Accessibility Act.

DRM, encryption.xml and why some EPUBs will not open

A DRM-free EPUB opens in any conforming reader. Many books bought from stores or borrowed from libraries are not DRM-free, and the encryption is recorded inside the container itself. When META-INF/encryption.xml is present, it lists which resources in the archive are encrypted and with which algorithm, using W3C XML Encryption syntax.

Three schemes dominate. Adobe ADEPT ties the book to an Adobe ID and requires Adobe Digital Editions or another ADEPT-authorised app (the book is usually delivered through an intermediate .acsm token). Readium LCP is an increasingly common passphrase-based scheme used by libraries and European stores. Apple and Kobo apply their own store DRM. A generic reader that opens a plain EPUB will refuse a protected one, or prompt for an Adobe ID, because it cannot decrypt the resources encryption.xml marks. The same encryption.xml mechanism is also used, without any DRM, for the specification’s optional font obfuscation, a light scrambling of embedded font files that a reader must reverse before rendering.

EPUB, MOBI and sending to Kindle

Historically the awkward part of EPUB was Amazon: Kindle used its own MOBI and later KF8/AZW3 formats, so users converted EPUB to MOBI to read on a Kindle. That advice is now outdated. Since late 2022 Amazon’s Send to Kindle (the web uploader, the desktop and mobile apps, or the personal @kindle.com email address) accepts an EPUB directly and converts it to the device’s internal format on Amazon’s side; MOBI was dropped from Send to Kindle in the same change. Copying an EPUB to a Kindle over USB still does not work, so for USB sideloading you convert to AZW3 in Calibre, but for everyday use sending the EPUB is simpler. DRM-protected EPUBs are rejected by Send to Kindle, which is the practical wall library books hit.

Frequently asked questions

Is an EPUB really just a ZIP file?

Yes. Rename a .epub to .zip and any archive tool shows the XHTML chapters, CSS, images and the OPF metadata inside. The one rule that separates it from an ordinary ZIP is the first archive entry: an uncompressed file named mimetype holding the string application/epub+zip, which is how software identifies the container.

Why does my EPUB ask for an Adobe ID or refuse to open?

It is DRM-protected, which is typical for store purchases and library loans. The container includes a META-INF/encryption.xml file listing encrypted resources, most often under Adobe ADEPT or Readium LCP. Open it in the app the book was issued for (Adobe Digital Editions authorised with the same Adobe ID, or Thorium for LCP). Generic readers only open DRM-free EPUBs.

Why does the same EPUB look different on two devices?

Because EPUB reflows. The book is XHTML plus CSS, and each reading system applies its own default styles, fonts and the reader’s chosen font size when it lays the content out, so line breaks and pagination differ by design. Only fixed-layout EPUBs, which pin content to a set viewport, look identical everywhere.

References