# Are some real world compression algorithms sometimes producing unexpectedly large files?

Lossless compression is not magic. It just gives the common patterns a short notation, compensating by the less common patterns ending up with a longer notation. By that logic, all lossless compression algorithms must sometimes give you a larger file back. A real world example of that is for instance giving a file containing 'a' and a line feed to gzip (2 bytes), it subsequently returns a 30 byte file. In general, compression tools do not break even for very small files.

My question is: Are some compression utilities bloating out larger files by some significant amount? (While "Give this file to 7z and watch you harddrive fail!" is cool, things like "This 4kb file will grow to 6kb." are also good.)

I can see a reason why such behaviour might not exist. If you for instance always put an extra bit to the output telling if the file is actually compressed, or just the original file in the cases where the compression fails, your output can never be worse than the original file plus 1 bit. I am however not sure if any such protection against unexpected large files is used.

• I don't see how this is a question about computer science. It just seems to be, "Hey, are there any inputs that make some program behave badly?" Note that it's trivial to write a compression program that ensures that no string ever grows by more than one character (If the string has been compressed, store "0" followed by the compressed string; otherwise, store "1" followed by the original) so this just boils down to asking about the behaviour of software currently in use. – David Richerby Jul 25 '16 at 9:17
• @DavidRicherby It is more like that compression programs can be written in one of two ways here, and I wonder what is actually chosen in practise. – SE - stop firing the good guys Jul 25 '16 at 9:31
• Then that is not a question about computer science. – David Richerby Jul 25 '16 at 9:36
• So this is a survey? This makes your question off-topic. – Evil Jul 25 '16 at 11:58

I have generated $256 \text{ bytes}$ file with consecutive numbers.
Compressed as 7z LZMA: $349 \text{ bytes}$, LZMA2:$356 \text{ bytes}$, Deflate or Deflate64: $400 \text{ bytes}$, bz2: $388 \text{ bytes}$, PPMd: $421 \text{ bytes}$ so not that cool.