n8n Compression node: zipping and unzipping files inside a workflow

Any n8n workflow that handles files eventually runs into an archive: three attachments to bundle before sending, a .zip dropped on an SFTP server by a partner, a 200 MB CSV export to shrink before upload. The Compression node covers both symmetric needs — creating an archive and extracting one — with no code and no external binary. This guide walks through its actual parameters, the patterns that work, and the three limits that break most first attempts.

What the Compression node does

It is a core node, no credential required, with two operations:

• Compress: builds an archive from one or more binary properties of the current item.
• Decompress: extracts the contents of an archive held in a binary property.

The Compress parameters fit on a single screen:

• Input Binary Field(s): the name of the binary property to compress, data by default. For several files, list the names separated by commas — data,data2,data3.
• Output Format: Zip, Gzip, Tar or Tar (Gzip).
• File Name: the name of the produced file, for example documents.zip. This field only appears for container formats (zip, tar, tar.gz), since they group several entries under a single name.
• Put Output File in Field: the binary property that will receive the archive, data by default. Rename it (archive, say) if the item already carries a file in data, otherwise you overwrite the source.

With Gzip the logic changes: gzip compresses a stream, not a directory tree. Each listed input property is compressed separately and the node uses an Output Prefix to name the outputs — gzip on three files gives three .gz files, not one archive. If you want a single downloadable file, pick Zip or Tar (Gzip).

On the Decompress side, two parameters are enough:

• Input Binary Field(s): the property holding the archive (again, several names separated by commas).
• Output Prefix: the prefix of the created binary properties, file_ by default, to which the node appends an incrementing index. A three-file archive therefore yields file_0, file_1, file_2 on the same output item.

The n8n documentation states that the operation recognizes the extensions .zip, .gz, .gzip, .tar, .tar.gz and .tgz. A .tar.gz is extracted in one pass: no need to chain a gzip Decompress and then a tar Decompress.

Under the hood, zip and gzip both rely on DEFLATE, itself built on the algorithm published by Jacob Ziv and Abraham Lempel in "A Universal Algorithm for Sequential Data Compression" (IEEE Transactions on Information Theory, 1977). Hence the gap in results: a CSV or a JSON file, highly redundant, compresses heavily, whereas an already compressed PDF or JPEG gains almost nothing.

Bundling several attachments into one archive

This is the most requested use case, and the one people start wrong most often. The Compression node works item by item: three files spread across three items produce three archives of one file each. To get a single zip, the three files must live on the same item, in distinct binary properties. Two ways to gather them:

1. A Merge node in Combine mode to aggregate parallel branches, making sure the binary properties do not share a name (otherwise the last one overwrites the others).
2. A Code node in Run Once for All Items mode, rebuilding a single item:

const binary = {};
for (const [i, item] of $input.all().entries()) {
  binary[`data${i === 0 ? '' : i + 1}`] = item.binary.data;
}
return [{ json: { count: $input.all().length }, binary }];

The Compression node that follows then receives data,data2,data3 in Input Binary Field(s), produces delivery.zip in the archive property, and the Gmail or SMTP node downstream attaches that single property: one attachment instead of ten, and a total size that usually drops back under the mail server limit. File names inside the archive come from the fileName of each binary property, so set them cleanly upstream — the full retrieval pipeline is covered in our guide to processing email attachments with AI.

Unzipping an incoming archive and processing each file

The reverse path is a staple of partner exchanges: a .zip dropped nightly on an SFTP server, or received as an attachment. The typical workflow is four nodes:

1. Trigger — Schedule plus an FTP/SFTP node in Download mode, or an Email Trigger (IMAP). The transfer side is detailed in our article on transferring files over SFTP with n8n.
2. Compression, Decompress operation, on the property holding the archive. Output: file_0, file_1, file_2… on a single item.
3. Code to split those properties into one item per file — necessary, because most downstream nodes (Extract from File, Google Drive, S3) handle a single binary property at a time.
4. Per-file processing: a Switch node on the extension, then Extract from File for CSV and XLSX (see our guide to Excel and CSV files in n8n), an upload to Google Drive for PDFs, and so on.

Step 3 takes a few lines:

const bin = $input.first().binary;
return Object.keys(bin).map((key) => ({
  json: { fileName: bin[key].fileName },
  binary: { data: bin[key] },
}));

One useful precaution: computing a SHA256 hash of every extracted file with the Crypto node lets you skip files already handled on a redelivery — partners often drop the same archive twice.

Compressing an export before archiving or upload

Third use case: shrinking a file before shipping it elsewhere. CSV exports, log dumps, database extracts — anything textual compresses heavily, and compressing before an S3 Put cuts both the storage bill and the transfer time (the full pattern is in our article on archiving files to S3 with n8n). Same logic for workflows exported as JSON before a push, covered in our guide to backing up and versioning n8n workflows with Git.

The reflex that "compressing always wins" deserves a caveat, though. Kenneth C. Barr and Krste Asanović, in "Energy-Aware Lossless Data Compression" (ACM Transactions on Computer Systems, 2006), measured the energy consumed by several lossless compressors before wireless transmission and found that with several common tools the balance is negative: the CPU cost of compressing exceeds the energy saved on sending. Transposed to n8n, the principle holds: on an already compressed file (PDF, JPEG, MP4) or a small file sent over a local network, the compression step costs RAM and time for no gain. Keep it for large volumes of text.

The memory trap

The Compression node loads everything in memory: during the operation, the n8n process holds both the source files and the produced archive. Compressing a 500 MB CSV therefore needs well over 500 MB of available RAM, and failure shows up as the familiar JavaScript heap out of memory, whose causes are detailed in our dedicated article on the heap out of memory error in n8n.

Three concrete measures:

• Switch binary storage to filesystem mode (N8N_DEFAULT_BINARY_DATA_MODE=filesystem) so binary data does not systematically travel through the executions database — the mechanics are detailed in our guide to handling large files and binary data in n8n. This does not remove the memory needed during the compression itself.
• Process files in small batches with a Loop Over Items node rather than aggregating twenty attachments onto one item before zipping.
• Raise NODE_OPTIONS=--max-old-space-size if your volumes are structurally large, keeping headroom against the container's RAM.

Beyond a few hundred megabytes, an Execute Command node calling zip, tar or gzip stays leaner: the system binary writes to disk as it goes instead of holding everything in RAM. That option assumes shell access on the instance, so it rules out n8n Cloud.

Security: an incoming archive is not a trusted file

Two blind spots worth addressing explicitly. No password support, first: the node exposes no encryption parameter: it neither creates protected archives nor opens them — an encrypted .zip simply makes the Decompress operation fail. To move sensitive documents, encrypt at the transport layer (SFTP, time-limited signed link) rather than relying on an archive password.

An incoming zip is untrusted input. Automatically decompressing an archive received by email means opening third-party content inside your infrastructure. The risk is not theoretical: David Fifield showed in "A Better Zip Bomb" (13th USENIX Workshop on Offensive Technologies, WOOT 2019) that a 10 MB archive, non-recursive and fully format-compliant, can expand to 281 TB after a single round of decompression — enough to saturate an n8n worker with a file that looks harmless. Three guardrails:

• An IF node on fileSize before the Decompress, and a cap on the number of properties produced after it.
• An allowlist of senders or extensions: .zip remains a favoured vector for slipping an executable past an antivirus filter. Our article on AI phishing and spam detection in n8n covers the upstream triage.
• An execution timeout on the workflow, so a pathological decompression stops on its own.

Key takeaways

The Compression node comes down to two operations and five parameters: Compress (Input Binary Field(s), Output Format, File Name, Put Output File in Field) and Decompress (Input Binary Field(s), Output Prefix). Most of the work happens around it: gathering several files onto one item with distinct binary properties before zipping, then splitting them back into items after unzipping. Three limits remain — everything runs in memory, there is no password handling, and an archive from outside deserves a size and origin check before it is opened.

Going further

The Inbox AI Pack (€79) chains reception, triage and processing of email attachments, archives included. For workflows where extracted files must be traced and retained properly, the Compliance & Audit Pack (€149) provides the matching audit trail.