Create and convert archives in a mixed batch

ZIP is the universal choice: every operating system opens it without extra software, and each file inside is compressed individually, so a single entry can be pulled out cheaply. TAR is the unix convention — it bundles files and their structure into one uncompressed stream, which is why it so often travels as TAR.GZ, the same bundle squeezed through gzip as a whole.

That difference drives real decisions. Sending files to a non-technical recipient or a Windows machine? ZIP, no discussion. Feeding a toolchain, server, or developer workflow that expects unix conventions? TAR or TAR.GZ. TAR.GZ often compresses a folder of similar text files tighter than ZIP because it compresses the stream as one piece — but the whole stream must be decompressed to reach anything inside.

Container conversion is the everyday archive job: a TAR.GZ arrives from a Linux-side collaborator and the person who needs it next only knows how to double-click a ZIP. Add the archive to the queue and its row exposes the other supported containers as outputs. Pick ZIP, run the row, and the contents and their folder structure are carried into the new container unchanged — the files inside are repacked, not re-encoded or altered.

The direction works both ways, so ZIP to TAR.GZ is equally routine when a deployment process or build system on the receiving end expects the unix format. Because the work happens locally, repacking is also a reasonable way to peek at a suspicious archive's structure without handing it to a third-party website. And like every route, the repack must pass the output gate — the new container has to prove well-formed before the download unlocks, so a truncated or corrupt source archive surfaces here rather than on the recipient's desk.

Sometimes the container is just in the way: the photos you actually want to convert are sitting inside a ZIP someone sent you. Extraction unpacks the archive locally so the individual files land back in your hands, ready to be fed into whatever comes next — image rows, data rows, or plain saving to disk.

This is where the queue becomes a pipeline. Extract the ZIP of HEIC photos, drop the extracted photos into the same workspace as image jobs, set their outputs to JPG, and run. Two archive rules to remember before you start: contents come out as they went in, so a broken file inside an archive is still broken outside it, and encrypted or password-protected archives cannot be opened — decrypt with the password holder's tool first.

The mirror image of extraction is bundling: after converting a set of files, collect the finished outputs into a single ZIP instead of downloading a dozen loose files. One archive is easier to email, attach to a ticket, or drop into shared storage, and it keeps a delivery together as a unit — the client gets "the assets," not eleven separate downloads to lose track of.

Bundle at the end of the pipeline, not the start. Convert the images to their final formats and the data to its final shape first, check the results, then create the archive from the outputs you have verified. Zipping first and converting later just means opening the archive again. Give the bundle a name that describes the delivery — client, contents, date — so it stays identifiable long after it leaves your hands.

Now combine everything. A genuinely mixed queue — HEIC rows converting to JPG, a JSON row becoming CSV, a TAR.GZ row repacking to ZIP — runs as a set of independent jobs. Each row keeps its own compatible outputs, so nothing about the archive rows constrains the image rows, and each row succeeds or fails alone. One unreadable file does not cost you the other nine results.

Sequence the work the way the dependencies point: extractions early (their outputs feed other rows), conversions in the middle, bundling last. Keep the tab open and in the foreground while a heavy batch runs, since every job is competing for the same browser memory, and remove finished rows you no longer need to give the remaining work room.

Archive routes carry specific limits: compressed inputs up to 200 MB, at most 5,000 entries, and at most 512 MB expanded. These are deliberate archive-bomb and memory protections — a tiny malicious file can claim to expand into terabytes, and a browser tab has to refuse that class of input outright. If a legitimate archive trips a limit, split it at the source into a few smaller archives and process them as separate rows.

Archive downloads also draw from their own daily allowance — currently 10 per local calendar day, with the remaining count shown beside the download action. Plan bundling accordingly: one deliberate ZIP of a checked batch spends the allowance better than five experimental repacks. And as always, validated results live at temporary URLs, so save the archive before closing the session, then open it once locally and spot-check a few entries before sending it anywhere.