Three inputs contain exactly 65,536 bytes each. Their compressed sizes are 85, 162 and 65,562 bytes.
One input repeats the letter A. Another repeats the short pattern ASTERXOR|, cut to the same total length. The third contains seeded pseudorandom bytes. The local experiment sends all three through zlib at level six, then decompresses every result. Equal starting length produces dramatically unequal output length, while every recovered byte still matches its source.
The opportunity is in the pattern, not just the amount of data.
A repeated passage need not be written again
Imagine a message that repeats a phrase many times. A compact description can point back to the earlier phrase and say how much to reuse. DEFLATE, the compression format used inside this zlib stream, combines references to repeated byte sequences with coding that assigns efficient bit patterns to symbols. The decoder follows the description to reconstruct the original.
This is a lossless bargain. The experiment checks the entire decompressed byte string for equality rather than deciding whether it merely looks similar. There are no image-quality settings, visual tolerances or discarded details here. A shorter representation is successful only if it restores exactly the same input.
Structure changes the result
At level six, the repeated A input becomes 85 bytes and the repeated nine-byte pattern becomes 162. The pseudorandom input becomes 65,562 bytes, slightly larger than its 65,536-byte source. Those are measured lengths of the complete zlib outputs, including their format overhead rather than just a hypothetical compressed payload.
The difference between the two patterned inputs also matters. Compression does not simply count how many distinct byte values appear. The arrangement and lengths of repeated sequences, the coding choices and the stream format all contribute. Both examples are predictable, but they do not require identical descriptions from this encoder.
A larger file can be the correct result
Independent-looking bytes offer fewer useful repetitions for a general-purpose compressor to exploit. The encoder still needs a valid stream with framing and integrity information. Here that leaves the pseudorandom example 26 bytes larger. The program did not damage the input or fail its round trip; it simply found no size advantage worth more than the overhead.
This one fixture is not proof that the generator produces true randomness, nor that every random-looking string will grow by the same amount. A compressor is also not a universal randomness test. Its success or failure depends on which kinds of structure it knows how to describe and the amount of data available.
A stronger setting does not invent a pattern
The script also tries levels one, six and nine. Repeated A measures 308, 85 and 85 bytes. The repeated pattern measures 355, 162 and 162. The pseudorandom input remains 65,562 bytes at all three settings. In these particular examples, moving from six to nine changes none of the output lengths.
Compression levels guide an encoder’s trade-offs; they are not a percentage of information preserved. All tested settings remain lossless. This experiment measures only output size, not CPU time or memory use, so it cannot say which level is fastest or cheapest for a real workload. A dial can search harder for an opportunity that the input barely offers.
No lossless scheme can shrink everything
There cannot be a unique shorter binary description for every possible fixed-length binary input: there are not enough shorter descriptions to assign one to each input. Some inputs must stay the same size or grow if all information is to be recovered. Real formats also need practical structure, which adds its own costs.
That counting argument does not tell you how well a particular document will compress. It does explain why “make every file smaller without changing anything” is not a universal promise software can keep. Test the actual material, preserve the original when needed, and compare the full stored sizes. Predictability creates opportunities, but the chosen format decides how much of them it can use.
Further reading
Python: zlib compression and decompression ↗IETF RFC 1951: DEFLATE format ↗IETF RFC 1950: zlib stream format ↗Original documentation and useful background.