Why does my LZ77 compressor produce larger text files?

Make sure the output is being written as a binary format and that you are measuring the actual compressed data rather than an intermediate buffer or text rendering of it. It can also help to include a stored, uncompressed mode: if compression does not reduce the payload after headers and metadata are counted, write the original bytes instead.

Lossless compression cannot make every possible input smaller. If it did, you could repeatedly compress the result until every file became zero bits, which is impossible because there are more possible inputs than shorter outputs. Random or already-compressed data has little predictable structure, so it may stay the same size or get larger. Ordinary text usually compresses well, but the file needs to be large enough for the savings to outweigh the format overhead.

Exact decompression only proves that your process is reversible; it does not prove that the representation is efficient. For a text file that is tens of kilobytes and still grows substantially, check whether you are finding the longest useful matches and whether your sliding window is large enough. Also avoid writing every position and length as oversized fixed-width integers—using 32-bit fields for each token can easily waste more space than the match saves.

This can be completely normal, especially for small files. A compressed format needs headers and metadata, and each encoded match usually has to store things like a position and length. If those fields take more space than the repeated text saves, the result grows. Try a much larger, highly repetitive file; you should see the compression become more effective. Your later test shrinking about 5 MB to 850 KB is a good sign.