Zlib compress

It is the same deflate compressed data with a different wrapper. A zlib stream has a small two byte header and an Adler-32 checksum, while gzip has a larger header carrying a name and timestamp plus a CRC-32. zlib is what you want when another program expects a zlib stream, for example inside a PDF or a PNG chunk. For a file you will hand to someone, gzip is the more usual choice.

Your file name with .zz appended, keeping the original extension, so data.bin becomes data.bin.zz. Zlib decompress strips that suffix back off. The .zz extension is a convention used here so the pair round trips, not a standard everyone follows. Any program expecting a zlib stream will read the contents whatever the file is called.

No. The tool takes no options and uses the fflate default for every run, so compressing the same bytes always gives the same result. There is no level, no dictionary and no window size setting. The gzip and deflate tools here work the same way, since all three call into fflate with its defaults.

It depends on the content, and the tool promises nothing. Text and structured data compress well; already compressed images, video and archives hardly move and can grow slightly because of the header and checksum. Compressing an already compressed file twice does not help.

Yes. It works per file, so each file you drop comes back as its own .zz, named from its own source, processed one after another and listed separately. Nothing is bundled together, so reach for Create tar or Create ZIP first if you want one file at the end.

No. Compression runs in a Web Worker in your tab with nothing sent to a server. Both the input and the output are held in memory at once, so the size you can handle is set by your device rather than by any limit in the tool.