Last I remembered, the "Kindle" format was identical to the MobiPocket ".mobi" format, which was just a dumbed-down ePub using a different compression format.
http://en.wikipedia.org/wiki/Comparison_of_e-book_formats "Kindle" .azw format is "identical" to .mobi except that it uses a proprietary encryption format. Mobi *way* predates ePub, so if you will, ePub could be considered a "more modern" format than Mobi, not Mobi is a "dumbed down" version of ePub. In terms of rendering, Mobi format can be, and often is, faster, in part because it relies on "lazy evaluation" -- which may not always result in correct rendering at the start of a page when a document is opened "in the middle", but which potentially (and in practice) can lead to much faster loads of documents than ePub. ePub in turn *does not* specify a "standard" encryption format. Many vendors follow the Adobe encryption standard [and license software renderers etc. from Adobe] which potentially allows their encrypted ePubs to be compatible and readable on each other's devices. Apple I believe uses their own incompatible encryption scheme. While both Mobi and ePub are specified nowadays based on IDPF, in practice implementations rendering those efforts interpret the guide structure standards differently, resulting in practical incompatibilities re display of "index" information, such that naïve conversion of ePub to Mobi doesn't result in a usable "index" on most Mobi rendering devices [read: Kindle, in practice, for most people today]. [My read of the IDPF standards is that most ePub authors don't implement index info correctly in the first place, relying instead on messed-up Adobe proprietary conventions for displaying guide info in lieu of a "correct" index implementation -- but we've had this argument before] If you read the IDPF stuff carefully [and if one reads the HTML stuff carefully] it really doesn't say how most of this stuff needs to be "correctly" rendered, simply that it needs to be correctly parsed, allowing device manufacturers to simply ignore that which they don't want to implement. Examples being color support, or lack thereof, and what fonts, if any, are supported, and how. Device support for generic fonts, for example, tends to be horribly "messed up", ill-implemented, and ill-supported, such that HTML documents originally designed for the desktop, with "very carefully specified" font schemes, still end up being rendered horribly messed-up when auto-converted to ePub or Mobi and rendered on a particular device. Not to imply that even IF that "desktop" HTML document *were* "correctly" rendered on a ePub or Mobi device that the end result would necessarily represent any useful result. It probably wouldn't be -- which is why the device manufacturers tend to ignore font specifications in the first place. "EPUB Straight to the Point" by Elizabeth Castro is one more-or-less useful intelligent book on these issues. "How to Create an eBook with Adobe® InDesign® CS5" by Rufus Deuchler also has some intelligent thoughts [not to imply that using InDesign is one of them] His page http://rufus.deuchler.net/2010/10/css-and-xhtml-tags-for-epub.html is an intelligent discussion of the problems -- and a decent example ePub (that can also automagically be converted to mobi by Amazon Kindle on the Desktop Emulator program) He says something intelligent there which is frequently ignored by people who think they know HTML and/or eBook authoring: "The first lesson in ePub [and Mobi] is that designers and publishers have very little control over the formatting of their eBooks." [And they would be better off if they didn't try to assert such control in the first place!] One common mistake one sees in practice at PG and other places is that authors and implementers performing horrendous feats of HTML "secure" [incorrectly] in the knowledge that they "know" the HTML standard and thus that what looks cool on their desktop browser and OS is going to automatically look cool on other people's desktops, browsers, laptops, netpads, tablets, and ebook readers. On the contrary, the more effort they put into making the HTML "look cool" on their desktop the more likely it will look horribly screwed up on almost everyone else's desktops, browsers, laptops, netpads, tablets, and ebook readers! KISS. PS: Trying to implement "Drop Caps" in HTML, ePub, and/or Mobi being one common example of this disease. PPS: Trying really fancy and complicated coding of Poetry being yet another example! PPPS: Even trying to specify paragraph indent style, and/or blank line or lack thereof between paragraphs is frequently messed up!