MOBI and AZW: The KF7 Binary Layout

Status. MOBI and AZW (KF7) are legacy. Current Kindle store files are KF8 (AZW3) and KFX. The tables on this page describe KF7 and the MOBI half of a dual KF8 file. This page does not describe KFX internals. Adapted from the MobileRead Wiki page MOBI (last revised 2026-04-14). Forum links and download links are citations only; this site does not mirror forum posts. The header fields were reverse engineered. Where the source page marks a field unknown, this edition keeps that mark. No offset below was filled in from anywhere else.

MOBI is the name of the format built for MobiPocket Reader. Amazon still uses the same container under a different DRM scheme and calls the result AZW. KindleGen wrote files with that extension which actually hold two books: a MOBI (sometimes called KF7) book and a KF8 book. The tables here cover the MOBI side of that pair, and a standalone KF7 file. They do not describe the KF8 half beyond the boundary fields the MOBI header uses to find it, and they do not describe KFX.

What the file is

MOBI is what MobiPocket Reader and the Amazon Kindle readers open. The extension may be .mobi or .prc. Either extension is recognized, and either file may or may not carry DRM. The .prc extension exists because Palm OS only allowed two file extensions, .prc and .pdb.

Mobipocket did not allow its DRM scheme to be used on a dedicated ebook reader that also implemented some other DRM. Source documents for the format are OEB (Open eBook).

What changed inside it

MOBI began as PalmDOC plus a set of HTML-like tags in the text. See eBook HTML. Many MOBI files are still that simple form. There is also a higher-compression form that packs the same data with a proprietary Huffman scheme called Huff/cdic. Third-party code that reads the original form is fairly common. Third-party code that reads the Huffman form is not. A Python implementation lives in the Calibre tree as huffcdic.py.

Features were added over time, so a new file can fail in an old reader. Source documents follow the Open eBook rules.

AZW and MOBI are the same file format. The difference is the DRM scheme. Amazon bought MobiPocket. The layout below applies to both extensions.

Palm container

Like PalmDOC, a Mobipocket file is a Palm Database. The header carries a database name, usually the book title and sometimes part of the author's name, at most 31 bytes. The file is identified by creator id MOBI and type BOOK.

Mobipocket published a thin description of the format, mostly the HTML used in the book text. The official page is gone; the archive copy is the mobipocket.com developer note. HTML as Mobi7 used it is also on eBook HTML.

PalmDOC header

The first Palm record holds the Mobipocket details. Its first 16 bytes are almost the PalmDOC header.

Two things differ from a PalmDOC file. Compression type 17480 exists, and the Current Position bytes are reused:

Legacy Mobipocket encryption registers the file to a single PID. The current scheme allows more than one PID on the same file. Unless a sentence says otherwise, encryption on this page means the current scheme.

MOBI header

Most files continue record 0 past those 16 bytes with a MOBI header. Newer files follow that with an EXTH header. Both live in record 0 of the Palm database.

The MOBI header has no official documentation and its length varies. The fields below are a partial identification. Every row from the source page is kept, including fields whose meaning is still unknown. Two hex labels are copied as the source page prints them: offset 252 is labeled 0xfb, and offset 268 is labeled 0x10b.

EXTH header

If the MOBI header says an EXTH header is present, it begins immediately after the MOBI header. Because the MOBI header length varies, EXTH has no fixed offset inside record 0. Some readers ignore the whole EXTH header when the Mobipocket version stored in the MOBI header is 2 or less (possibly 3 or less).

EXTH is also undocumented. Part of what follows is inference.

Many record types have been seen. The list below is every type the source page records, with the meaning that was suggested for it. Usual length is blank where the source page left it blank.

The rest of record 0

The full filename is usually stored at the end of Palm record 0, at the offset the MOBI header gives.

Between the end of the EXTH records and that filename there may be bytes whose purpose is not known.

After the filename come two null bytes, then more nulls out to a 4-byte boundary. The length stored in the header does not include those nulls. If the name is 16 bytes, two nulls make 18, and two further nulls bring the stored run to 20, while the header length stays 16. If the name is 19 bytes, two nulls make 21, and three further nulls bring the stored run to 24.

Past the name and that padding, record 0 continues with more bytes of unknown purpose, usually nulls, until the record ends.

Index meta record

The first record of an index holds the index metadata.

The rest of the INDX header is unknown.

TAGX section

TAGX follows the INDX header. It is what makes the index values decodable. It says how many control bytes each entry has, which bits belong to which tag, and how many values a tag takes. Most tags take one value. Some take two. More than two is possible.

Each tag-table entry is a multiple of 4 bytes. The first byte is the tag, the second is how many values it has, the third is a bit mask, and the fourth marks the end of the control byte. If the fourth byte is 0x01, every remaining byte of that entry is zero.

Variable-width integers

Some Mobipocket structures encode integers with a variable number of bytes. The integer is big-endian. Each byte carries 7 payload bits (bits 1–7). A forward-encoded integer sets bit 8 only on the least significant byte. A backward-encoded integer sets bit 8 only on the most significant byte. The number 0x11111 forward-encoded is:

0x04 0x22 0x91

Backward-encoded it is:

0x84 0x22 0x11

Trailing entries

The Extra Data Flags field in the MOBI header says which trailing entries, if any, are appended to each text record. Each set bit corresponds to one entry. The entries seem to follow bit order: trailing entry 1 sits just after the text, and entry 16 sits at the very end of the record. The role of most entries is unknown. Entries selected by bits 2 through 16 seem to share one layout:

<data><size>

<size> is the size of the whole trailing entry, including the size field itself, written as a backward-encoded Mobipocket variable-width integer.

Only a few bits have been identified:

Multibyte character overlap

When bit 1 of Extra Data Flags is set, each record ends with a trailing entry that holds the extra bytes needed to finish a multibyte character cut by the record boundary. Those bytes are not compressed, whichever compression the file uses. Unlike other trailing data, the overlap bytes, including the count byte, are encrypted. The same overlap bytes then appear again as ordinary content at the start of the next record. The entry ends with one byte that stores the overlap count plus further flags.

PalmDOC compression

PalmDOC uses LZ77. One implementation is palmdoc.c. A DOC file can hold only compressed text. The format itself has no typography, which matches Palm's preference for small files. Extensions of the format put formatting in the text with tags, for example HTML or PML. Those extensions do not interchange with each other. They are the base of most ebook formats on Palm devices.

LZ77 replaces a span of bytes with a pointer at a match that has already passed through the encoder and the decoder. A match is a length-distance pair: the next length characters each equal the character distance bytes earlier in the uncompressed stream. "Distance" is sometimes called "offset."

In PalmDOC a length-distance pair is always two bytes. Of those 16 bits, 11 encode the distance, 3 encode the length, and 2 mark the first byte so the decoder can recognize the pair. The exact unpacking steps are on the PalmDOC page. This page does not restate a bit diagram the source does not give.

PalmDOC data is always cut into independent 4096-byte chunks, measured uncompressed. Compressing or decompressing one chunk needs nothing from the chunk before it or the chunk after it.

PalmDOC also has bookmarks: named pointers at offsets in the file. Editing the file can leave a bookmark aimed at the wrong place. Some readers let the user edit bookmarks, some treat them as a table of contents, and some ignore them. They are stored at the end of the file, so a reader has to scan the whole file to find them.

Image records

If the file has images, the image records follow the text records, one image per record. The 4096-byte record size in the PalmDOC header applies only to text. An image record may be larger.

Magic records

MobiPocket Creator sometimes inserts a record of two zero bytes after the text records. That record is not included in the PalmDOC header's text record count, and it is not the record named by "first non-book index" in the MOBI header. When the two-zero record is present, the first non-book index is the index of the next record after it.

MobiPocket Creator also ends the file with three records, in this order: FLIS, FCIS, and end-of-file. For MobiPocket Reader and the Kindle 2, FLIS and FCIS do not seem to be required in order to read the file. The end-of-file record might be required.

FLIS record

FLIS seems to be a fixed pattern. What the values mean is not known.

FCIS record

FCIS is mostly fixed values as well.

End-of-file record

The end-of-file record is always 4 bytes. The last two bytes look like a CRLF. The meaning of the first two is unknown.

Compilation records

KindleGen inserts records of the sources it compiled (KindleGen 1.2 through 2.5), or those sources plus the compiler's own output (KindleGen 2.7 and later). In KindleGen 1.2 through 2.2 those records sit immediately before the end-of-file record. In KindleGen 2.3 and later they sit immediately before the BOUNDARY record.

A MOBI file built with Mobipocket Creator, Amazon's Personal Document Service, or Kindle Direct Publishing (formerly Amazon DTP) has no SRCS record. KindleGen once had an undocumented switch that suppressed the record. That switch was removed in 2010.

The SRCS record is a zip of every source file passed on the command line (.opf, .ncx, .htm, .jpg, and the rest), stored inside the MOBI file. It starts with the signature SRCS:

The CMET record is the compiler's output, possibly with some further data. It starts with the signature CMET:

Media records (AUDI / VIDE)

KindleGen can embed audio and video for some Kindle platforms. Each media file is its own AUDI (audio) or VIDE (video) record:

The MBP sidecar

.mbp is the extension of the sidecar that travels with a MOBI book. Library software stores metadata there, and the reading program stores what the user does: bookmarks, annotations, and the last reading position. The reader creates the file the first time the book is opened. MobiPocket's library software reads the sidecar for the title, author, and description it shows in the library window, so it does not have to open the larger book.

A description of the binary MBP layout is in progress at that page. The same site has an mbp reader that extracts notes from an .mbp file.

Making a MOBI file

As of 2026 there is no officially supported tool that creates MOBI files. That is a practical problem for dictionaries: Kindle devices still accept only MOBI dictionaries when a dictionary is sideloaded.

Kindling is an open-source (MIT) MOBI writer, built by reverse engineering, and it can write dictionaries. Its repository also has further notes on the file format.

Tools that used to do this job are MobiPocket Creator, MobiPocket Reader (Windows), and KindleGen. Those are historical.

Authoring rules

These rules are what the format needs if a book is going to use MobiPocket Reader's features properly:

• Do not set a default font family, a default size, or other default font properties such as weight or color. That choice belongs to the person reading the book. A heading or some other special element may set a size and other properties. Use generic font families only.
• Do not force full justification on body text. A caption or other special text may need it.
• Do not use tables except for tabular data. Nested tables are not supported.
• Do not fake a page break with blank lines. Use the <mbp:pagebreak/> tag.
• Do not ship a separate edition of the book for each device. Use the format's own facilities, such as multi-resolution images and platform-specific frames.

Images for old PDA screens

This section applies only to original MOBI. Amazon AZW files do not use it.

An img tag in a Mobipocket publication can carry up to three source attributes, src, losrc, and hisrc, so one book can carry art tuned to different screens. The reader picks the image from the real screen size:

<img hisrc="cover480x640.gif" src="cover220x300.gif" losrc="cover140x140.gif"/>

There is also an internal ceiling of 63KB, a limit of the Mobipocket .PRC format. A GIF must be under 63KB. A GIF optimizer such as Ulead Smart Saver can bring a GIF under that line. If the image is larger than 63KB, MobiGEN scales it down to the limit on its own, and the result may not be the one you wanted. JPEG is handled differently: the encoder lowers the quality setting instead of reducing the pixel dimensions.

HTML and CSS while building MOBI

• The Kindle and the Kindle DX do not handle the soft-hyphen HTML entity correctly. Use the <shy/> tag instead.
• On some devices gray text is drawn white. Avoid that with a media query:

@media  amzn-mobi and (monochrome) {
        .mygreytextclass {
                color: black;
        }
}

• KindleGen ignores padding-left. When you need that inset, put another element inside and set its left margin.
• KindleGen's CSS parser is sometimes wrong. A rule written as:

div.foo p {
 ...
}

is often read as:

div.foo, div.foo p {
 ...
}

When the style should hit only the inner element, give those paragraphs their own class and select that class alone.

Further notes aimed at KF8 readers are on KF8 CSS Tips. KF8 is the other half of a dual KindleGen file. It is not KFX, and this page does not describe KFX.

Limits of the format

• The right margin cannot be made larger than the normal margin.
• The left margin can only be set in steps of 1em. A hanging indent is possible only when there is no left margin. Newer Kindle renderers raised that left-margin step to about 2em.
• Text cannot wrap around an image that is taller than one line of text.
• Image size does not scale with the font size.
• In some Mobipocket renderers, but not all of them, text that has a left margin changes that margin on each line according to the font size at the previous line break.
• Many measurements, including the size of a hanging indent, cannot be given in em.
• An individual run of text cannot be set in a monospace font.
• Tables behave very differently from one Mobipocket renderer to another, especially a table that crosses screens.
• Nested tables are not supported at all.
• The full range of Mobipocket formatting is available only when the markup follows Mobipocket's own HTML 3.2, which is non-standard, extended, and poorly documented. The archived tag reference is the file tag reference.

MOBI DRM

A MOBI file can optionally carry DRM. This section describes how the lock is applied. It is not a removal guide. In some countries removal is illegal on its own, and in the United States the DMCA prohibits circumvention. That boundary is stated on the DRM page. This article does not name removal tools or steps.

Three schemes show up in the source page.

The standard scheme is backed by Mobipocket and OverDrive servers. It is based on an id derived from the reading device or the reading program. When the book is bought, the server has to know that PID. The PID is embedded in the file and the file is locked to the device. The same scheme can allow several devices, usually up to four, and in that case the server has to know every device id. After a device is added, the server has to be told and the book has to be downloaded again before the new device can open it. Adding a device or downloading again is usually free. If the retailer disappears, there may be no way to add a device later, because there is nowhere left to download the file.

A second, simpler scheme needs only the account name and password used to buy the book. Once those are entered, the book opens, and each device only has to be told once. This scheme is newer, and some readers may not implement it.

A third method, used on some books, encrypts the file with a generic MOBI key rather than a key for one PID. Any MobiPocket Reader on any device can read it. Software that is not MobiPocket Reader cannot.

The lock covers the book, not the metadata. A library routine can read the metadata without unlocking the book. Programs have been written that change that metadata without touching the DRM portion of the file. That is a statement about where the metadata sits. It is not a procedure for altering or removing the lock.

Readers and converters

Besides the official MobiPocket reader, the source page lists:

• Calibre
• Kindling
• Stanza, a historical product line. The iOS app looks unmaintained since August 2013.
• FBReader
• Book Designer
• STDU Viewer
• Sumatra PDF
• Kindle for PC or Kindle for Mac
• KindleUnpack, formerly called MobiUnpack. The source page describes it as a tool that turns a MOBI file back into the pieces it was built from, and also calls it a MOBI decoder. This page does not describe it as a way to remove DRM.
• PDF to EPUB/Mobi converter
• KindleGen, Amazon's tool for turning an EPUB into Mobi (AZW) or otherwise producing a Mobi file. Official support for creating MOBI this way has ended; see the note at the start of "Making a MOBI file."

Hardware readers

• Bookeen Cybook Gen3
• Bookeen Cybook Opus
• Hanlin V3 / BeBook / EZ Reader
• iRex iLiad
• iRex Digital Reader
• Amazon Kindle readers
• Onyx BOOX readers

Devices that open MOBI do not all implement the same subset. What each one actually does is on Mobi Comparison.

Building a MOBI file from an EPUB

The recipe below is the one the source page gives. It depends on MobiPocket Creator, which is no longer an officially supported creator. It is a build procedure, kept here as documentation of that workflow.

1. Keep the table-of-contents entries you care about on h1, h2, and h3 only (the reason is step 9, unless you use step 10 instead).
2. Finish the EPUB in Sigil, importing each HTML file with "add existing item" as you go.
3. Finish the EPUB without a cover page yet.
4. Install MobiPocket Creator.
5. Unzip the EPUB.
6. Double-click the OPF.
7. The book opens in MobiPocket Creator.
8. Drag the cover into MobiPocket Creator.
9. Have MobiPocket Creator build an html table of contents that uses only heading levels 1, 2, and 3. Or:
10. Edit the Guide Properties so MobiPocket Creator points at an html table of contents you already have. The source page notes that toc.ncx is already in the right place, in the "My Publications" folder under the MobiPocket Creator directory.
11. Click Build.
12. The result is a working PRC file.

Further reading

• Mobipocket Creator download, a free download when that page was current, and the wiki's MobiPocket Creator page. The product is historical.
• Mobipocket development center, the old production documentation.
• Content generation. The section on paragraph formatting describes CSS-like behavior. MOBI itself has no CSS.
• Amazon KindleGen, the successor to mobiGen. The source page says it is enough to produce a MOBI book. Treat the product as historical.
• KindleGen on MobileRead Wiki, for how it was used.
• MobileRead forum note on unpacking a MOBI file. Citation only.
• Java MOBI metadata editor, a forum thread about editing, adding, and deleting EXTH tags. Citation only.