making bbPress (and WordPress) work better!

zopfli gzip compressor – binary for Windows

Google recently opensourced an interesting little project in C called ZOPFLI to try to get the most compression possible out of gzip which is one of the only universal compression available in browsers.

This is useful for things that are compressed once and served many times, for example jquery, stylesheets, etc. But in my testing, Zopfli only does very slightly better than 7zip’s ultra gzip compression set at mx9, and zopfli takes much much longer. It’s an interesting experiment but perhaps pointless.

If you want to try it, you can get it at:

git clone

Alternately if you are on windows, you can use MinGW to easily compile it into a command line utility that works exactly like it’s linux counterpart. Note that you may have to fix your mingw install by copying a few files or changing your path.

Or if you are lazy and feel you can trust me, here is a zopfli windows binary


92629 bytes  jquery-1.9.1.min.js  
31783 bytes  7z.exe -mx9 -tgzip a "jquery-1.9.1.min.js.gz" "jquery-1.9.1.min.js"
31688 bytes  zopfli.exe -v --i1000 "jquery-1.9.1.min.js"

Note this is only a comparison of gzip/deflate so even if bzip or xz is 10k smaller, it’s pointless because browsers cannot natively decode that.

zopfli also took a VERY long time compared to 7zip

Before you argue that 100 bytes saved served many thousands of times is significant, remember that a TCP/IP packet is rounded typically to 1500 bytes or so. 100 bytes is meaningless unless it saves an extra packet, which it will probably not.

6 responses

  1. “100 bytes is meaningless unless it saves an extra packet, which it will probably not.”

    Or if you are Google and happen to serve a gazillion files per day. Think of all the sites hot linking I don’t know how many times a day that gets requested, I’d guess it to be a fairly large number though. If they can make that smaller via a one time compression process, then that will probably multiply out to a reasonable win.

    March 2, 2013 at 6:13 pm

  2. w/held

    I have a feeling that very compressible text data is not a great test of zopfli, in my 25mb test 7zip was actually about 10k smaller, tho kzip was smaller still.

    February 2, 2015 at 6:34 pm

  3. w/held

    ^ using deflate not lzma of course 😛

    February 2, 2015 at 6:36 pm

  4. Anonymous

    PNGZopfli is a way of compressing png files using Zopfli. After they’ve been compressed they still open normally. When I use your zopfli.exe on them, no matter what the settings, I can’t get them to open normally. Are there similar implementations of zopfli like PNGZopfli, but for other formats, like WOFF or TTF?

    March 19, 2015 at 2:29 pm

  5. Dennis

    ” remember that a TCP/IP packet is rounded typically to 1500 bytes or so.”

    TCP packets are not rounded up or padded, so this simply isn’t true. There is an overhead per packet (about 64 bytes), and it will be split across multiple packets, but they are most certainly not fixed sized.


    January 30, 2016 at 12:17 pm

  6. Your binary has a bug – it corrupts files written to stdout. The stdout is in text mode and should be in binary, like this:

    #if defined(__MSVCRT__) || defined(__OS2__)
    setmode( STDIN_FILENO, O_BINARY );
    setmode( STDOUT_FILENO, O_BINARY );

    Not sure whether it should be `#if defined(WIN32)’ but __MSVCRT__ seems to be defined in mingw as well, so it should work. I didn’t check cygwin, I don’t have compiler.

    April 21, 2018 at 8:31 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s