# KindleUnpack opens a non-DRM Kindle file into editable parts > KindleUnpack is a Python tool that takes a non-DRM Kindle or MobiPocket ebook and unpacks it into the parts it was built from, and the output depends entirely on the format: HTML and images for the old Mobi files, a PDF for Print Replica, and an epub-like structure for KF8. It is a migration and repair tool rather than a reader, and its last tagged release is from 2020. **kevinhendricks/KindleUnpack** — python based software to unpack Amazon / Kindlegen generated ebooks - Repository: https://github.com/kevinhendricks/KindleUnpack - Stars: 1,103 · Forks: 114 - Language: Python - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/kevinhendricks-kindleunpack ## It reverses a conversion, it does not remove protection The description is short. KindleUnpack is python based software to unpack Amazon and Kindlegen generated ebooks, and it unpacks a non-DRM Kindle or MobiPocket ebook into its component parts, which change depending on the type of Kindle or Mobi ebook being processed. The non-DRM qualification is in the first sentence of the description and it is the boundary that matters. This is a tool for files that have no protection scheme, and the documentation does not describe, hint at or attempt any way of handling a file that does. That is a different category of software from the tools that strip protection, and it is why this project is a repair and conversion utility rather than a way to obtain books. The other half of the description explains the real use case. Amazon and Kindlegen both take a source document and produce a packaged file, and the packaged file loses information. The information is still there, in the form of the original assets, and unpacking recovers it. That is what makes the tool useful for the two common cases, a book whose conversion is broken and needs to be rebuilt by hand, and a book that was produced from an epub and needs to go back to being an epub. The provenance is in the licence notice. The program is based on an initial mobipocket version by Charles M. Hannum, with extensive extensions and improvements credited to P. Durrant, K. Hendricks, S. Siebert, fandrieu, DiapDealer, nickredding and tkeo between 2009 and 2014. The licence is the GNU General Public License version 3. The audience is a technical user with a specific file in hand, and the tool is a utility rather than a product. ## Four input formats, four different outputs The output structure is decided by the input format, and the documentation is explicit about each case. MobiPocket and early Kindle version 7 or less ebooks are unpacked to the original HTML 3.2 and images folder, which can then be edited and reprocessed by MobiPocketCreator. This is the most complete round trip, because the HTML and the images are the actual source that was compiled into the file. Kindle Print Replica ebooks are unpacked to the original PDF and any associated images. There is nothing to reconstruct here, the PDF is simply extracted with its images. Kindle KF8 only ebooks, the .azw3 files, are unpacked into an epub-like structure. The documentation is careful here. The result may or may not be a fully valid epub, and that depends on whether a fully valid epub was originally provided to kindlegen as input. The note says the generated epub should be validated using an epub validator, and that if changes are needed it should load properly into Sigil or Calibre, either of which can be used to edit the result to create a fully valid epub. Newer Kindle ebooks which have both KF8 and older versions inside are unpacked into two different parts, the older MobiPocket format ebook parts and the epub-like structure that can be edited using Sigil. The last case is the one that explains the tool's continuing usefulness. A file that contains both formats is a file that was packaged from a source and then converted, and unpacking it gives you both the modern structure and the legacy one, which is what you need when a reader is refusing to open it. ## The epub output is described as epub-like, not as epub It is worth spending a paragraph on the honesty of the wording around the KF8 case, because it sets the expectation correctly. The documentation does not say the tool produces an epub. It says it produces an epub-like structure, and then it says the output may or may not be a fully valid epub depending on what kindlegen was given. The validation step and the two suggested editors, Sigil and Calibre, follow immediately. That is a technical truth about the whole conversion pipeline. An epub is not just a zip of files, it has an OPF package document, a navigation document, a fixed layout or reflowable mode, and a set of metadata rules, and a converter that assembles the parts of a mobi or an azw3 back into something that looks like an epub is reassembling from information that did not necessarily contain all of that. If the source was a well formed epub, there is a good chance the result is one. If the source was a PDF that went through Print Replica, it may not be. The practical instruction in the documentation is therefore not optional. Run the generated file through an epub validator first, and if it fails, open it in Sigil or Calibre and fix it there. A user who assumes the output is a valid epub and loads it into a reader without checking will spend a long time on a file format error before suspecting the tool. The same applies to the MobiPocket output, which is described as editable and reprocessable by MobiPocketCreator, which is a different tool and a different part of the workflow. ## Installing means unzipping, and the .pyw has to stay next to lib There is no package manager entry and no build step. The installation instructions are to find a location on the machine and fully unzip it, with one hard rule: do not move the KindleUnpack.pyw program away from its associated `lib` folder. The reason is in the next sentence. If you have a proper Python 2.7 or later installation, you should be able to double-click the KindleUnpack.pyw icon and the GUI interface should start. The .pyw extension is what makes that work on Windows, and the library folder is where the support modules live, so moving the launcher out of the tree breaks it in a way that produces a traceback rather than a helpful message. For a command line user, the instructions are to look inside the `lib` folder for the KindleUnpack.py program and its support modules and run it from there. The repository layout matches: `KindleUnpack.pyw` and the `lib/` and `libgui/` directories are at the top level, alongside `DumpMobiHeader_v023.py`, a separate header dumping utility, and `KindleUnpack_ReadMe.htm`. The Python requirement is old and the documentation is candid about it. The program requires Python 2.7.X or Python 3.4 or later. On Windows the project strongly recommends the free version of ActiveState's Active Python 2.7.X or 3.4.X or later, because it properly installs all of the required parts including the tk widget kit and updates the system path, and the official installer from python.org sometimes does not properly handle this on Windows. On Mac OS X 10.6.X and later and on almost all recent Linux versions the required Python is already installed as part of the official OS installation, so users there need to install nothing extra. The practical consequence for a modern user is that the Python 2.7 and 3.4 era instructions are the ones in the documentation, and you are expected to sort out an interpreter that satisfies them. The repository has seen commits as recently as 2026-05-21, so the code is not frozen, but the most recent tagged release is v0.83 from 2020-12-28, with v0.82 from 2019 and v0.81 from 2018 before that. ## The command line options that change the output The command line is the version of the tool that a script would drive, and the usage line is short. ```sh python kindleunpack.py [-r -s -d -h -i] [-p APNX_FILE] INPUT_FILE OUTPUT_FOLDER ``` Two positional arguments do the work. `INPUT_FILE` is the path to the desired Kindle or MobiPocket ebook, and `OUTPUT_FOLDER` is the path to the folder where the ebook will be unpacked. The options change what comes out rather than where it goes. `-h` prints the help message. `-i` uses HDImages to overwrite lower resolution versions if present, which matters for a file where the images were stored in both a low and a high resolution form. `-s` splits combination mobis into older mobi and mobi KF8 ebooks, which is the explicit version of the two part output described above. `-r` writes raw data to the output folder, and `-d` dumps headers and other debug info to output and extra files, which is the switch to reach for when the unpack is not behaving. There is also `--epub_version=`, which takes 2, 3 or A for automatic, or F to force EPUB2, with the default being 2. Since the KF8 output is epub-like rather than guaranteed valid, this option is how you ask for the older, more forgiving format when a reader rejects a version 3 file. So the options fall into three groups. The ones that change the output format, `-i`, `-s` and `--epub_version`, the ones that change what is written out, `-r` and `-d`, and the one that changes where it goes, the output folder argument. ## The apnx page offset trap is the one to read before using -p The `-p` option deserves a separate look, because the documentation includes a warning that is easy to skim past. The option takes the path to a .apnx file that contains real page numbers associated with an azw3 ebook, and it is optional. The warning is that many apnx files have arbitrarily assigned page offsets that will confuse KindleUnpack if used. An apnx file is a page number index. A book that was converted from a PDF has real page numbers, because the PDF had them. A book that was converted from reflowable HTML does not, so the conversion invents a numbering that points at arbitrary locations in the text. Feeding that invented index to a tool that is trying to reconstruct the book produces a result that is wrong in a way that is difficult to spot, because the file still opens and the page numbers still resolve, they just resolve to the wrong places. The safe rule is that `-p` is only appropriate when the source was paginated and the apnx genuinely reflects the printed page numbers. Otherwise leave it off. The bug reporting route is also unusual and worth knowing. The documentation asks for bugs and comments to be reported on the sticky forum on the Mobileread website, under E-Book Formats, then Kindle Formats, then KindleUnpack, which is also known as MobiUnpack. That is a forum rather than the repository's issue tracker, and it is a sign of the project's age and its community rather than an oversight. ## Where KindleUnpack is the wrong tool The limits are clear and mostly follow from the format. The first is that it does nothing for protected files. The documentation says the tool unpacks a non-DRM ebook, and there is no described path for anything else. If your file is protected, this is not the tool, and the fact that a similar sounding tool exists elsewhere does not change that. The second is the output quality. As the KF8 case shows, the output is reconstructed rather than recovered, and whether it is a valid epub depends on what the original conversion was given. A user whose goal is a perfect epub and who has no way to validate the result is going to spend time on a file format problem. That is a workflow requirement, not a defect, but it has to be planned for. The third is that it is old. The documented Python requirements are 2.7 or 3.4, the Tk based GUI is a technology that has moved on, and the newest tagged release is from December 2020. Commits have continued since, with the last one on 2026-05-21, so the code is not abandoned, but there is no recent release to point at, and the documentation has not been rewritten for a current Python. The genuine alternative, and the difference in approach is real, is not another unpacker but a different strategy. If the file is a Kindle format that came from a PDF, the PDF is usually the better artefact and Print Replica extraction gets you there directly. If the file came from an epub, then a tool that reads the azw3 as an epub in the first place, rather than unpacking and reassembling, avoids the reconstruction problem entirely. And if the only goal is to read the book, a reader opens the file without any of this. The cases where KindleUnpack is the right answer are the ones where you need the parts, which is exactly what the tool is for. ## Conclusion KindleUnpack suits someone who owns a non-DRM Kindle file and needs it as editable HTML, an epub-like structure or a PDF, for example to fix a broken conversion or to feed a file into Sigil or Calibre. It is the wrong tool for a DRM protected book, which the documentation explicitly excludes, and the wrong tool when the output only needs to be read, since a reader does the same job with less risk. Check first which of the four input formats your file is, because the output structure differs, and validate the generated epub with an epub validator before editing it, since the tool states the result may not be a valid epub. ## FAQ ### What does KindleUnpack do? It unpacks a non-DRM Kindle or MobiPocket ebook into its component parts, with the output structure depending on the format. MobiPocket and early Kindle files become the original HTML 3.2 and images, Print Replica files become the original PDF and images, and KF8 only .azw3 files become an epub-like structure. ### Is the epub produced by KindleUnpack always valid? No. The documentation says the KF8 output may or may not be a fully valid epub depending on whether a fully valid epub was originally provided to kindlegen. It says the generated epub should be validated with an epub validator and, if changes are needed, edited in Sigil or Calibre. ### How do I install and run KindleUnpack? Fully unzip the download somewhere on your machine and do not move `KindleUnpack.pyw` away from its `lib` folder, since the GUI launcher needs the support modules beside it. You can then double-click the .pyw icon, or run `python kindleunpack.py [-r -s -d -h -i] [-p APNX_FILE] INPUT_FILE OUTPUT_FOLDER` from inside the `lib` folder. Python 2.7.X or 3.4 or later is required. ### What does the -p option do and when should I use it? It supplies the path to a .apnx file containing real page numbers for an azw3 ebook. The documentation warns that many apnx files have arbitrarily assigned page offsets that will confuse KindleUnpack, so it is only appropriate when the page numbers genuinely reflect the printed pages. ## Sources - [Issues](https://github.com/kevinhendricks/KindleUnpack/issues) - [kevinhendricks/KindleUnpack on GitHub](https://github.com/kevinhendricks/KindleUnpack) - [License: GPL-3.0](https://github.com/kevinhendricks/KindleUnpack/blob/master/LICENSE) - [README](https://github.com/kevinhendricks/KindleUnpack/blob/master/README.md) - [Releases](https://github.com/kevinhendricks/KindleUnpack/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kevinhendricks-kindleunpack