A zip bomb is a compressed file, designed so that unpacking it yields the biggest file possible. These are fairly well known, and there are examples of 42 KB files which expand into multiple petabytes of data.

In this challenge, the goal is reversed. Instead of providing a compressed file which is then unpacked, the goal is to provide an uncompressed file which is compressed in an unreasonably inefficient manner, ideally becoming larger than the original.


You should provide a file between 10 KB and 1 GB, which will be compressed by your chosen algorithm. You should also specify a compression algorithm, such as gzip or PNG. If the algorithm allows things like a compression level to be set, different configurations count as different algorithms. The algorithm can be lossless or lossy, and can be application specific (like PNG or MP3).

Submissions are scored based on the ratio of \$\frac{\text{compressed}}{\text{original}}\$. For example, an 80 KB file that "compresses" to 88 KB would get a score of \$1.1\$. The highest scoring solution, per algorithm, wins.

  • \$\begingroup\$ How should we provide the file, 1 GB sized files would be too large, so should we have to share a link of a file sharing provider service (Such as Google drive or Mega.nz)? \$\endgroup\$
    – Wasif
    Mar 29, 2021 at 15:36
  • 1
    \$\begingroup\$ @Jonah The goal is to provide a file which becomes larger when it's compressed. A normal zip bomb would become larger when it's decompressed (or significantly smaller when the expanded file is compressed) \$\endgroup\$ Mar 29, 2021 at 20:42
  • 1
    \$\begingroup\$ @EthanChapman "You should provide a file between 10 KB and 1 GB" \$\endgroup\$ Mar 29, 2021 at 22:53
  • 3
    \$\begingroup\$ @EthanChapman I didn't read it that way, due to "the goal is to provide an uncompressed file which is compressed..." \$\endgroup\$ Mar 29, 2021 at 22:55
  • 1
    \$\begingroup\$ @user253751 The same as writing a custom language to solve a challenge in zero bytes, basically. This is a competition within compression algorithms, like how Jelly doesn't compete with Java, so if you're fine with competing in the "unzip with lots of downvotes" category go ahead :p \$\endgroup\$ Mar 30, 2021 at 12:07

7 Answers 7


FFmpeg -crf 0 -preset ultrafast -tune film -vf format=yuv444p, score 198.7425

Input is a 65535 × 1 PBM file:


This image consists of repetitions of the following 16-pixel pattern:

enter image description here

The input file is exactly 10,000 bytes: the first 8203 bytes encode the image (one bit per pixel plus the 11 byte header); the last 1797 bytes are padding.

The input is 'compressed' into a single-frame lossless H.264 video using FFmpeg, yielding a 1,987,425 byte MP4 file as output. The following Ruby script generates both files:

#!/usr/bin/env ruby
raw = 'raw.pbm'
cmp = 'compressed.mp4'
File.write(raw, 'P4 65535 1 ' + 'IE'*4994 + 'I')
system("ffmpeg -i #{raw} -crf 0 -preset ultrafast -tune film -vf format=yuv444p -frames 1 #{cmp}")
puts File.size(raw)
puts File.size(cmp)

The compression/quality options passed to FFmpeg are:

  • -crf 0 (constant rate factor 0). From the docs: 'You can use -crf 0 to create a lossless video . . . Note that lossless output files will likely be huge'.

  • -preset ultrafast 'A slower preset will provide better compression', so I chose the fastest one. (The next fastest option, superfast, reduces the file size more than fivefold.)

  • -tune film Adding this option ('use for high quality movie content; lowers deblocking') increased the file size by 2 bytes.

  • -vf format=yuv444p Adding this option (no chroma subsampling) increased the file size by 1 byte.

For comparison, with the default compression/quality settings (ffmpeg -i raw.pbm -frames 1 compressed.mp4) the compression ratio is 4.44558. With maximum compression and lowest quality (ffmpeg -i raw.pbm -crf 51 -preset veryslow -frames 1 compressed.mp4) the compression ratio is 1.4147.

Pattern selection

Images encoded only by repetitions of one of I, E, ), %, 0x15, or Q result in MP4 files that are at least 9.5 % larger than for any other byte. These six patterns all have a white:black pixel ratio of 5:3 with no two black pixels adjacent to each other. I tested all repeated permutations of these six bytes up to size six, finding that the pattern encoded by repetitions of IE yielded the largest file size.

One might guess that a random image would result in a larger MP4 file than a regular pattern. I have found no such image. Across 10,000 trials with images encoded by random combinations of the six bytes identified above, the maximum file size was 1,961,715 bytes (average 1,961,005). Across 10,000 trials with completely random images, the maximum file size was only 1,514,853 bytes (average 1,499,010).

In an older version of this answer I used -filter:v fps=10000000 instead of -frames 1, resulting in a much higher compression ratio, without realising that the output contained thousands of frames (thanks to @MT0 for the comment). This seemed like an unfair advantage, as more frames containing the same image could be added to increase the file size at will.

  • 4
    \$\begingroup\$ This is converting a single frame into a movie. How many frames are in the output? Because if it is more than 1 frame then this feels like a disingenuous solution and you should use -frames 1 in the ffmpeg arguments. \$\endgroup\$
    – MT0
    Mar 30, 2021 at 9:33
  • 6
    \$\begingroup\$ @MT0 Not so much disingenuous as ignorant, but you make a good point. Edited. \$\endgroup\$
    – Dingus
    Mar 30, 2021 at 10:05
  • 1
    \$\begingroup\$ If the image is random, does that increase the size? (I don't know how video compression works) \$\endgroup\$ Mar 30, 2021 at 13:08
  • 1
    \$\begingroup\$ @thedefault. That was my first thought too, but seemingly not. Across 1000 trials with random (B&W) images the largest file size was 1,511,062 bytes, average 1,499,044. \$\endgroup\$
    – Dingus
    Mar 30, 2021 at 13:53

JPEG (4:4:4 Chroma subsampling), ~1584.35

Asking Redwolf about what the input file type for a PNG is, we hear that it's

Any file you can get an implementation of a PNG converting program to accept.

I realized that this means we're essentially looking for a file which compresses really well in one format but really horribly in another. I initially looked for something PNG couldn't compress well but JPEG could, but I soon realized it was easier to go the other way around.

To construct my image, I started with this 8x8 pattern:

enter image description here

Here, horizontal rows are either full green or no green, and vertical rows are either full red or no red. PNG's two compression steps are both perfect for this kind of pattern. The filter uses color data from the left and top pixels, while the interlacing groups into even-dimensioned checkerboard patterns. Better yet, this means that PNG will repeat this sequence for a while with relatively small changes to file size compared to image size. My final PNG is 3840x3840: enter image description here This takes up 11,198 bytes and has a CRC-32 of 4979FF24. I converted this to a JPEG in Paint.net, with 100% quality to make sure the exact same image came out and 4:4:4 chroma subsampling so it couldn't cheat a little with the colors, and received a 17,741,541 byte file with a CRC-32 of B6B4AC7D. The overall ratio between these two files is about 1584.35.

  • 3
    \$\begingroup\$ "You should provide an uncompressed file" PNG is not uncompressed. \$\endgroup\$ Mar 30, 2021 at 4:51
  • 8
    \$\begingroup\$ @thedefault. It is uncompressed in the sense that it hasn't been compressed with the chosen algorithm yet. Sorry for any confusion! \$\endgroup\$ Mar 30, 2021 at 5:03
  • 6
    \$\begingroup\$ Just a note: It is 7,372,918 bytes if you save it as 16 color BMP. (I'm using mspaint.exe on Windows) And it still smaller than JPEG. (score 2.406). \$\endgroup\$
    – tsh
    Mar 30, 2021 at 9:21
  • 6
    \$\begingroup\$ IMO the use of PNG to compress the raw data definitely inflates the score significantly here, though an alternate challenge to supply a compressed file that compresses very poorly in another format would still be interesting. \$\endgroup\$
    – gntskn
    Mar 30, 2021 at 13:21
  • 3
    \$\begingroup\$ @gntskn I agree! I think this is an answer which takes extreme advantage of the flexible input format, where there's little difference between a zip bomb and a reverse zip bomb if the "uncompressed" file happens to be in a format which supports compression. \$\endgroup\$ Mar 30, 2021 at 15:51

BSD Compress, 1.4746

Unlike gzip, compress doesn't check whether it would be cheaper to store an uncompressed block, so its worst case performance is much worse than gzip's. If you give it a file of completely random bytes, without any patterns or redundancies to take advantage of, compress fails miserably.

python3 -c 'from numpy import random; random.seed(29597); f=open("raw_file","wb"); f.write(random.bytes(1024*10))' && cat raw_file | compress > compressed_file && wc -c *_file

This doesn't work on Try It Online, since the TIO shell doesn't have compress installed, but my Macbook has it installed by default. When I run this, I get the following file sizes:

15100 compressed_file
10240 raw_file

For a ratio of 1.474609375

  • 4
    \$\begingroup\$ I'd be interested to see if there's any noticeable different with different seeds \$\endgroup\$ Mar 30, 2021 at 0:43
  • 2
    \$\begingroup\$ Good call. I just did a quick brute force search and improved this from 1.45 to 1.47 with a better seed. \$\endgroup\$ Mar 30, 2021 at 1:02
  • \$\begingroup\$ Nice find regarding the algorithm! \$\endgroup\$
    – w123
    Mar 31, 2021 at 17:16

BSD Compress, 1.5721

The following Python script constructs a file which compresses worse than a random file. It continually extends the current file by a random byte, samples 20 different random choices and continues with the file which compresses the worst. Running the script took 1.5 hours on my machine, because it tries the compression on more than 200 000 different files.

I used the implementation ncompress 5.0 on Windows.

import random as rnd
import subprocess as sp
import numpy as np

FILE_LEN = 10 * 1024  # 10 KiB

with open("file.txt", 'wb+') as f:
    for pos in range(FILE_LEN):
        arr = np.zeros(BYTE_RANGE, dtype=np.int_)
        random_bytes = rnd.sample(range(BYTE_RANGE), SAMPLES)
        for b in random_bytes:
            result = sp.run(["compress.exe", "-fc", "file.txt"],
            arr[b] = len(result.stdout)
        b_opt = np.argmax(arr)

Here are the stats:

raw - 10240 Bytes
compressed - 16099 Bytes

  • \$\begingroup\$ This is pretty cool! I'm glad to see more answers in general compression algorithms. \$\endgroup\$ Mar 31, 2021 at 12:34
  • 1
    \$\begingroup\$ Unfortunately, most general compression algorithms have a pretty tight upper bound on the "negative compression rate", because it's not uncommon that files or parts of them are almost random (e.g. any format with inbuilt compression). It's nice that water_ghosts found a format without literal blocks! \$\endgroup\$
    – w123
    Mar 31, 2021 at 17:21

gzip (RFC 1952), 10kb/9.976kb ≈ 1.0024057739

RFC 1952 represents the length of the name of the original file as a null-terminated string. Therefore, we can just use the following gzip of a 0-byte file with an arbitrarily long name:

1F 8B 08 08 A7 53 62 60 04 FF 41 41 41 41 41 41 41 41 41 41...
...41 41 41 41 41 41 00 01 00 00 FF FF 00 00 00 00 00 00 00 00

with enough As (0x41) to pad out our file to 10kb. Note that some header flags and settings can be modified as you please.

I'm not certain if any programs handle this correctly. After a certain length, longer than the Windows file name limit but shorter than this, 7zip declares the archive invalid, likely due to some kind of technical limitations. The Linux utility gz successfully returns a 0-byte file, but uses the name of the gzipped file rather than the specified name. I didn't bother to look more into it, since I'm confident that this is a valid gzip by the simple and straightforward wording of RFC 1952.

  • \$\begingroup\$ @Chartz Belatedly how should a compression format that uses the source file name be scored then? \$\endgroup\$ Mar 29, 2021 at 22:57
  • 4
    \$\begingroup\$ I don;t know, I'm not the challenge author. But, if I were, I'd just count the filename as part of the length, as we do in most cases where this comes up \$\endgroup\$ Mar 29, 2021 at 23:01
  • \$\begingroup\$ @ChartZBelatedly that sounds reasonable, but I'll leave this up until Redwolf clarifies. \$\endgroup\$ Mar 29, 2021 at 23:39
  • 1
    \$\begingroup\$ @EthanChapman This is invalid, I agree with ChartZ Belatedly on how using the source file's name should be counted. \$\endgroup\$ Mar 30, 2021 at 0:39
  • 1
    \$\begingroup\$ I've edited this to fix the score. Since you technically don't have a score of infinity, I think this is still a pretty clever idea but not a particularly good-scoring one. \$\endgroup\$
    – Makonede
    Mar 30, 2021 at 1:08

PCX (run length encoding of images). Ratio of 12 or 1131 depending on whether using uncompressed (though stored more efficiently) or compressed via different algorithm (e.g. png)

Using the PNG attached (because imgur supported it), I go from: 4860 bytes to 5500128 bytes for a ratio of 1131.7. Using a portable bitmap file (which imgur doesn't support), I lose color but now go from actually uncompressed 12059 bytes to 1500897 bytes for a ratio of about 12. (What I had hoped to do was get it to have worst case RLE (basically: it works by storing each pixel as a 1 byte symbol but does run length encoding, but if the pixel in question is >= 192, you have to store the run length of 1 so the parsing can determine what is a run length indicator (high 2 bits set to 1, lower 6 bits determine the run length from 0 to 63) and what is a pixel, so each pixel would require 2 bytes (and then there's the metadata)... didn't quite do that but will take this for now)

PNG version of input 1000x1000 pixel image with thin vertical stripes



wav source https://paste.ubuntu.com/p/DfRCHqWBXC/ . There's no absolute reason the data look like this.

compress command: ffmpeg -i a.wav b.mp3

ffmpeg create 8kbps mp3 even for 8bps wav


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.