Once you've finished authoring your ePub, you've got a folder full of HTML⁰, CSS, metadata documents, and other resources. The result is then stored in a standard Zip file and is then renamed to .epub. This is known as the Open Container Format (OCF).

There are actually a few different compression schemes for Zip files, but the specification says:

OCF ZIP containers MUST include only stored (uncompressed) and Deflate-compressed ZIP entries within the ZIP archive.

The Deflate algorithm is venerable¹ and, while incredible for its time, has been superseded by more modern compression schemes. For example, Brotli.

What happens if we unzip an ePub and then recompress it with Brotli? Will that dramatically reduce the file size?

Steps

• Unzip the book
  • unzip book.epub -d book/
• Brotli files can't contain directories, so tar the directory without any compression
  • tar -cvf book.tar book/
• Create a Zip file with maximum compression
  • zip -9 book.tar.zip book.tar
• Create a Brotli file with maximum compression
  • brotli -k -q 11 book.tar

Results

I took a random(ish) sample from Standard eBooks and a few from my personal stash².

The good news is that ePubs compress pretty well already! That isn't much of a surprise - compression algorithms love the repetitious nature of HTML and human-readable text. Obviously Brotli is better but, on the file sizes we're talking about, not dramatically better. Saving 60KB is OK - but in a world of terabyte sized SD cards does it matter?

Brotli is also computationally harder to decompress, which makes it slightly less attractive for low-powered eReaders.

It's also possible to make a small saving by reducing the complexity and verbosity of the CSS and HTML.

However, that's not the real problem.

I lied to you

An ePub contains more than just text and text-based metadata. It can contain web fonts, images, even music. The above books had all their fonts and media stripped out. Let's run the experiment again but, this time, including everything in the original book.

All of a sudden, Brotli makes next to no difference. Yes, the textual compression is still there, but it is overshadowed by the huge cost of the media files.

Mixed Media

The ePub 3.3 specification lays out which multimedia formats are acceptable. As well as the older formats like gif, png, and jpeg - newer formats like WebP are acceptable. Similarly, TTF fonts are listed in the standard along with WOFF2.

Modern image and font formats have better compression than their ancestors. Indeed, WOFF2 uses Brotli as its compression scheme.

The biggest filesize saving in ePubs comes from properly compressing images and fonts.

Can You Picture That?

It is a matter of opinion as to what resolution is best suited to an ePub. Most modern eReaders have, at best, 300ppi resolution. They're also normally monochrome. But eBooks aren't always read on low-resolution, black and white eInk screens - so it probably makes sense to have high-resolution colour images in order to future-proof books.

But the compression of those images is not a matter of opinion. Lossless compression algorithms are well supported for legacy and modern image formats.

Let's take a specific example. Twenty Years at Hull House is the 22MB book above. Less than a MB of that is for text, the rest is images.

The largest illustration in the book is a 1937x1971, transparent PNG weighing in at 1MB. Increasing the lossless compression level takes it down to 840KB. Reducing the palette to something more suitable takes it to 640KB. If you were releasing this as an ePub 3.3 file, using WebP would take the image to a hair over 600KB.

Basically, a 20%-40% filesize reduction with no loss of fidelity.

Across all the PNG images in the ePub, I was able to easily get the filesize from 20MB to 16MB.

Converting to lossless WebP got it down to 13MB.

What The Font?

Fonts can be shrunk in a number of ways. The most obvious way is to compress to WOFF2 which, as described above, uses Brotli compression.

Based on my quick tests, a typical ePub's TTF will see about a 50% reduction in font size. For typical "English" language fonts, that's a reduction from 30KB to 15KB. So big relative compression, but small absolute compression.

Complex decorative fonts can go from 800KB to 80KB. But it is rare for a font to exceed a megabyte.

If it does, that usually means that it has more glyphs than strictly necessary. If your book is written entirely in the Latin alphabet, do you really need all those fancy accents, Chinese ideographs, and emoji? Probably not.

I've previously written about Subsetting Fonts and the perils of excessive trimming.

Back to Basics

Brotli is magic - but changing the compression algorithm for the ePub standard is probably a false economy. The text portion of modern eBooks is already fairly small and compresses with reasonable efficiency.

The best compression gains come from either using next-generation image and font formats or, if legacy compatibility is necessary, using the most aggressive compression settings for traditional images.

The text of Shakespeare's Romeo and Juliet is about 146,000 characters long. Thanks to the English language, each character can be represented by a single byte. So a plain Unicode text file of the play is about 142KB.

In Adventures With Compression, JamesG discusses a competition to compress text and poses an interesting thought:

Encoding the text as an image and compressing the image. I would need to use a lossless image compressor, and using RGB would increase the number of values associated with each word. Perhaps if I changed the image to greyscale? Or perhaps that is not worth exploring.

Image compression algorithms are, generally, pretty good at finding patterns in images and squashing them down. So if we convert text to an image, will image compression help?

The English language and its punctuation are not very complicated, so the play only contains 77 unique symbols. The ASCII value of each character spans from 0 - 127. So let's create a greyscale image which each pixel has the same greyness as the ASCII value of the character.

Here's what it looks like when losslessly compressed to a PNG:

That's down to 55KB! About 40% of the size of the original file. It is slightly smaller than ZIP, and about 9 bytes larger than Brotli compression.

The file can be read with the following Python:

from PIL import Image
image  = Image.open("ascii_grey.png")
pixels = list(image.getdata())
ascii  = "".join([chr(pixel) for pixel in pixels])
with open("rj.txt", "w") as file:
    file.write(ascii)

But, even with the latest image compression algorithms, it is unlikely to compress much further; the image looks like random noise. Yes, you and I know there is data in there. And a statistician looking for entropy would probably determine that the file contains readable data. But image compressors work in a different realm. They look for solid blocks, or predictable gradients, or other statistical features.

But there you go! A lossless image is a pretty efficient way to compress ASCII text.

I wanted to go the other way. How good are modern codecs at dealing with tiny files?

Using GIMP, I created an image which was a single white pixel, and saved it as a PNG. I then used Squoosh to convert it to a variety of modern formats using different encoding options. This is what I found:

This is designed to be the "minimum viable viewable image". I loved Stoyan Stefanov's "Minimum viable no-image image src". That creates a 42 byte SVG with no image data in it - so I thought I'd see what happens if you make a displayable image.

Some important things to note:

• Older image formats like BMP and GIF are smaller than newer formats like AVIF.
• Some compression options make files larger in unexpected ways. The lossy WebP was larger than the lossless version.
• Similarly, increasing the effort on an AVIF can also result in a larger filesize.
• Neither JPEG XL nor QOI are supported in mainstream browsers yet.
• AVIF has a rather long and complex header - that makes sense for large images, but bloats it for smaller ones.
• Using Brotli, it is possible to further compress the AVIF (203 Bytes), JPG (69 Bytes), BMP (63 Bytes), and ICO (30 Bytes) files.
• WebP is the smallest file if you still need a Spacer.gif!

Here's my challenge to you - can you do any better? What's the smallest filesize you can find for a viewable image?

For years, HTTP content has been served with gzip compression (gz). It's basically the same sort of compression algorithm you get in a .zip file. It's pretty good!

But there's a new(er) compression algorithm called Brotli (br). It's Better, Faster, Stronger, Harder than gzip. Mostly.

Looking through my browser's request logs, I noticed everything was being transferred with Brotli compression except for one specific text file was being served as gz.

What's going on?

Well, let's take a look at the file's size.

curl -s "https://openbenches.org/api/benches.tsv" | wc -c

That downloads the file, counts the number of bytes, then formats it for readability. It's 2,727,104 bytes.

Now let's request it as a gzipped file:

curl -s -H'Accept-Encoding: gzip' "https://openbenches.org/api/benches.tsv" | wc -c It's 1,085,372 bytes.

Finally, requesting a Brotli compressed transfer: curl -s -H'Accept-Encoding: br' "https://openbenches.org/api/benches.tsv" | wc -c

That's 1,098,151 bytes. A whole 12,779 bytes larger!

My server was correct in using gzipped rather than Brotli for this specific file.

But, that's not the entire case here! I manually compressed the full file using different compression levels. Here's a quick graph showing the filesize at different compression strengths:

So, in this case, Brotli ≤ 3 is worse than gzip ≥ 5.

I suspect my host's server is configured to prioritise faster compression over absolutely smallest file size. That's probably a reasonable trade-off. I couldn't see a way to tell it to use a higher strength Brotli algorithm all the time - but I would probably be chasing marginal gains.

So, there you go. Don't be surprised if you occasionally see gzip where you expect to see Brotli.

If I set the compression to be lossy - the photo looks good but the UI looks bad. If I set the compression to be lossless - the UI looks good but the filesize is huge.

Is there a way to selectively compress different parts of an image? I know WebP and AVIF are pretty magical but, as I understand it, the whole image is compressed with the same algorithm and the same settings.

There are two ways to do this. The impossible way and the cheating way.

Selective Compression

In theory it should be possible to tell an image format to compress some chunks of an image with a different compression algorithm.

And yet... none of the documentation I've found shows that's possible.

GiMP's native XCF and Photoshop's PSD files work; they store different layers each of which can have a different filetype. I understand that TIFF and .djvu also have that capability.

But those sorts of files don't display in web browsers.

So...

Let's Cheat!

It's possible to use an SVG to embed multiple images of different formats. SVG is used as, effectively, a layout engine.

The syntax is relatively straightforward:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 1080 512">
   <image width="1080" height="512" x="0" y="0"
      xlink:href="data:image/jpeg;base64,..........."
   />
   <image width="1080" height="512" x="0" y="0"
      xlink:href="data:image/png;base64,..........."
   />
</svg>

That draws the JPG then draws the PNG on top of it. If the PNG has a transparent section, the JPG will show through. The JPG can be set to as low a quality as you like and the PNG remains lossless.

Here's what it looks like - click for full size:

Embedded images are Base 64 encoded, which does lose some of the compression advantages. But, overall, it's smaller than a full PNG and better quality than a full JPG.

Look, if it's stupid but it works it's not stupid.

But surely there must be a way of doing this natively?

Come on a thought experiment with me.

I have invented a new image compression format. It shrinks images to 50% smaller sizes than AVIF and is completely lossless. Brilliant!

There's only one problem - it is 1 million times slower.

If it takes your computer 10 seconds to compress an AVIF, it'll take 115 days to compress using my new format.

Is that worth it?

There are five aspects to think about here.

Time

If you're someone like, say, Netflix - this might be fine. You can throw a whole bunch of cloud servers at the problem, so you're not time-bound.

If you're a smaller service, or if you require instantaneous image compression, this is a pointless format. The time-cost - let alone processing costs - is prohibitive.

Space

If you're a library with billions of images - storage costs are a real concern. Halving those costs could save you more than it would cost to recompress all your images.

But storage is pretty cheap these days. Terabytes of storage are easily in range of home users. Is the cost of encoding worth it given that space isn't a limiting factor?

Transit

The Netflix logo is downloaded a hundred million times per day. So would a massive saving in bandwidth costs be worth the trade-off? Probably, yes.

If you pay per MB for your Internet access, you'll probably welcome this new codec. Saving money is great.

But how much does bandwidth really cost? Is it that expensive for either party?

User Experience

I've only mentioned the speed of encoding so far. Most codecs are asymmetric; they take a long time to encode but are fairly quick to decode.

Image formats like JPG and PNG are displayed practically instantly even on modest hardware. What if my wonderful new image format takes a couple of seconds to decode and display? That might be unacceptable. Asking the user to buy a new computer or upgrade their software may also be impossible.

Power and Pollution

I think this is what it comes down to. How much energy does it take to create and use these images? I don't know how much CO₂ it costs to transport a GB of data from one side of the planet to the other. And I don't know how energy efficient data centres are around the world.

I suspect that this is an impossible calculation. This daft image format would be a disaster if run on coal-powered server which sent data over a solar-powered fibre-optic cable. But, conversely, if we have a wind-turbine powered server sending data over the Deep Space Network to Mars (expensive and bandwidth-constrained) then this format is probably less polluting.

I worry that new compression formats face diminishing returns when faced with massive power costs. If the power required to encode and decode images continues to get larger, it could outstrip the savings made on transit and storage.