AZW3 File Documentation

Summary

An AZW3 (Kindle Format 8, KF8) file is Amazon’s e-book format, introduced in 2011 with the Kindle Fire as the successor to MOBI. It is a Palm Database (PDB) container that wraps HTML5 and CSS3 content, giving Kindle books styling, embedded fonts and fixed layouts. Its MIME type is application/vnd.amazon.ebook. Read it on any Kindle or the free Kindle app; DRM-free files open and convert in Calibre, but Amazon-purchased books are copy-protected.

Technical details

FeatureValue
Full nameKindle Format 8 (KF8)
File extension.azw3
MIME typeapplication/vnd.amazon.ebook
Format typeE-book container (Palm Database / PDB) wrapping HTML/CSS content
CategoryeBook files
DeveloperAmazon.com, Inc.
Introduced2011 (with the Kindle Fire)
Based onMOBI / PalmDOC lineage; adds a KF8 (HTML5/CSS3) section
Container / basePalm Database (PDB) file
Type / creator IDBOOK / MOBI at offset 60 (ASCII BOOKMOBI)
Magic numberNo fixed signature at offset 0; the first 32 bytes are the book name, BOOKMOBI sits at offset 60
Byte orderBig-endian (network byte order) throughout the PDB structure
Content markupHTML5 + CSS3; embedded fonts, drop caps, fixed and reflowable layout
DRMOptional Amazon DRM; ties the file to an Amazon account
CompressionPalmDOC LZ77 or HUFF/CDIC (Huffman)
Backward compatibilityOften carries a legacy MOBI (KF7) section for older Kindles
Open standardNo — proprietary to Amazon
Related extensions.azw, .mobi, .kfx, .epub, .prc, .pdf
SpecificationAmazon KDP — Kindle Format 8 (KF8) overview
File signature (Palm Database identifier)
42 4F 4F 4B 4D 4F 42 49

Offset 60, 8 bytes: the Palm Database type and creator IDs BOOK + MOBI, ASCII BOOKMOBI. There is no fixed signature at offset 0, because bytes 0–31 hold the book’s variable-length name. This same identifier marks older MOBI and AZW files, so it confirms the PDB/MOBI lineage but not KF8 specifically; the KF8 marker is the MOBI-type value 248 stored later, inside record 0.

What is an AZW3 file?

AZW3 is Amazon’s Kindle Format 8 (KF8), the e-book format introduced in 2011 with the Kindle Fire as the successor to the older AZW/MOBI format. The change from MOBI was not cosmetic. MOBI’s markup was limited, close to early HTML; KF8 embeds HTML5 and CSS3 content, so a Kindle book can carry proper styling: drop caps, nested tables, sidebars, embedded fonts and fixed layouts alongside the usual reflowable text. Amazon uses the extension for files created by KindleGen and by its later publishing tools.

Under that modern content, though, the file is old-fashioned in structure. AZW3 is a Palm Database (PDB) file, the same container lineage as MOBI and the original PalmDOC readers from the 1990s. A single .azw3 often actually contains two books in one: a KF8 section for modern Kindles and a legacy MOBI (sometimes called KF7) section so older hardware can still open it. Everything below describes how that PDB container is laid out, byte by byte.

The Palm Database header

Every AZW3 begins with the standard 78-byte PDB header. The layout is fixed and big-endian throughout.

Offset  Size  Field
0       32    Database name (the book title, null-padded)
32      2     Attribute flags
34      2     File version
36      4     Creation date
40      4     Modification date
44      4     Last backup date
48      4     Modification number
52      4     App info ID
56      4     Sort info ID
60      4     Type    = "BOOK"  (42 4F 4F 4B)
64      4     Creator = "MOBI"  (4D 4F 42 49)
68      4     Unique ID seed
72      4     Next record list ID
76      2     Number of records

The two fields that identify the file sit at offset 60: the four-byte type BOOK and the four-byte creator MOBI, which together read as the ASCII string BOOKMOBI. There is no magic number at offset 0, because the first 32 bytes hold the book’s name, which varies from file to file. Immediately after the header, at offset 78, comes the record-info list: one 8-byte entry per record, each giving that record’s absolute file offset (4 bytes) plus attribute and unique-ID bytes. This list is the table of contents for the whole container.

Record 0: the PalmDOC and MOBI headers

The first data record, record 0, is metadata rather than book text. It opens with a 16-byte PalmDOC header inherited from the format’s ancestry, then a variable-length MOBI header.

PalmDOC header (record 0, offset 0)
  0   2   Compression   1 = none, 2 = PalmDOC LZ77, 17480 = HUFF/CDIC
  2   2   Unused (zero)
  4   4   Uncompressed text length
  8   2   Record count for the text
  10  2   Record size (4096)
  12  2   Encryption type   0 = none, 2 = Mobipocket DRM
  14  2   Unknown

MOBI header (record 0, offset 16)
  16  4   Identifier "MOBI" (4D 4F 42 49)
  20  4   Header length
  24  4   MOBI type   2 = book, 248 = KF8
  28  4   Text encoding   1252 = CP1252, 65001 = UTF-8
  32  4   Unique ID
  36  4   File version

The compression field at offset 0 tells a reader how the book text is packed: value 2 is the PalmDOC LZ77 scheme, and 17480 is Amazon’s HUFF/CDIC Huffman compression used on larger books. The encryption field at offset 12 is where DRM shows up: 0 means the book is unprotected, while a non-zero value marks Amazon’s copy protection. Inside the MOBI header, the MOBI type at offset 24 is the KF8 marker: a value of 248 identifies KF8 content, distinguishing a true AZW3 from a plain MOBI, whose type is 2. The text-encoding field at offset 28 is almost always 65001 (UTF-8) for KF8 books.

EXTH: title, author, cover and ASIN

Directly after the variable-length MOBI header, still inside record 0, sits the EXTH header. This is where the human-facing metadata lives, and it is what lets a library app show a book’s title, author and cover without decoding the whole file.

EXTH header
  0   4   Identifier "EXTH" (45 58 54 48)
  4   4   Header length
  8   4   Record count
  12  ..  EXTH records follow

Each EXTH record:
  0   4   Record type   (e.g. 100 = author, 503 = title, 201 = cover offset)
  4   4   Record length  (including this 8-byte header)
  8   ..  Record data

Each EXTH record is a small type-length-value block: a 4-byte type code, a 4-byte length that includes the header, and the data. Type 100 carries the author, 503 the updated title, 104 the ISBN, 113 the Amazon ASIN, and 201 the record offset of the cover image. A reader walks record count entries to gather all the metadata. This structuring is the modern equivalent of the old, informal note that “metadata is stored at the beginning of the file so e-readers can identify the book without parsing all of it” — in KF8 that metadata is the EXTH block in record 0.

The KF8 content section and the legacy fallback

After the header records come the content records. In KF8 these hold the book as compressed HTML5 with CSS3 styling, plus supporting resources: embedded fonts, images, and the internal index structures (KF8 uses RESC, FLIS, FCIS and a BOUNDARY record to organise its sections). The HTML/CSS foundation is exactly what gives AZW3 its practical advantages over MOBI: authors get real control over presentation, with hyphenation, adjustable character spacing and justification, and the embedded fonts let a publisher hold a consistent typographic identity across devices.

The BOUNDARY record is the seam in a dual-format file. Because a single .azw3 commonly bundles both a KF8 section and a legacy MOBI section, the BOUNDARY marks where the old-format book ends and the KF8 book begins. An older Kindle that does not understand KF8 reads the MOBI half and shows a simpler version; a modern Kindle reads the KF8 half and shows the full styling. That is how AZW3 stays readable on older hardware while delivering richer layout on newer devices.

Amazon DRM and the account lock

Digital Rights Management is the practical friction with AZW3, and it is a rights mechanism, not a structural one. Books bought from the Kindle Store carry Amazon’s DRM, recorded by the encryption field in the PalmDOC header and a DRM voucher inside the file that ties the book to the purchasing Amazon account. On that account, across registered Kindle devices and apps, the book reads normally; off it, generic readers and conversion tools refuse to open the file. A .azw3 you create yourself, or download DRM-free, has the encryption field set to 0 and opens without restriction. Removing DRM from a purchased book breaks Amazon’s terms of service and may be unlawful where you live, so the honest position is that the format is open enough to read freely only when it is not protected.

Reading and managing AZW3 files

For account books, the official readers are the free Kindle apps and any Kindle device, which handle the DRM transparently. For DRM-free files, the standard tool is Calibre, which reads AZW3 in its built-in viewer and manages it in a library on Windows, macOS and Linux. Note the 2022 change in Amazon’s pipeline: Send to Kindle now accepts EPUB directly and converts it on Amazon’s side, while it dropped MOBI, so manually producing AZW3 or MOBI is less necessary than it once was. For sideloading your own files to a Kindle over USB, AZW3 (or the newer, more locked-down KFX) is still the format the device expects.

Frequently asked questions

Why won’t my AZW3 file open outside a Kindle?

Almost always DRM. Books bought from Amazon are copy-protected and tied to your account, so the encryption field in the file is set and generic readers refuse them. DRM-free AZW3 files — your own, or free books — open in Calibre and other readers without issue.

What actually makes a file KF8 rather than MOBI?

The MOBI-type field at offset 24 of record 0. A value of 248 marks KF8 (AZW3) content; a value of 2 is a plain MOBI. The outer PDB identifier BOOKMOBI at offset 60 is the same for both, so it does not distinguish them.

Why is an AZW3 file sometimes two books in one?

For backward compatibility. A KF8 file often bundles both a modern KF8 section and a legacy MOBI section, split by a BOUNDARY record, so older Kindles read the simpler MOBI half while newer devices read the fully styled KF8 half.

References