Compression Namespace in Apex: A Powerful New Salesforce Feature

Introduction

Working with documents inside Salesforce has always challenged developers because of the platform’s multitenant constraints. Previously, packaging and sending files in a compact form required external services, like an AWS Lambda function, that retrieved files via API and then compressed them.

With the introduction of the Compression Namespace and the powerful pre-defined Apex functions, you can now perform these tasks entirely within Salesforce boundaries. This brings significant benefits for Salesforce Apex Development, but it also comes with governor limits you must respect. Let’s dive into what this new feature means for developers.

What is Apex Compression Namespace?

Introduced in Spring 25 release, the Compression Namespace is a new Apex library added to the ever-growing list of native Salesforce functionalities. It makes it possible to create, read, and manage archived files (.zip extension) with Apex code, eliminating the need for leveraging external apps. The namespace provides the standard functionalities available when compressing files on your operating system.

You can specify:

Compression Level: Choose the right balance between processing time and file size. The available options in the Compression.Level enum are:

• BEST_COMPRESSION: Slowest to process, but produces the smallest size compressed file.
• BEST_SPEED: Fastest processing, but results in the largest compressed file size.
• DEFAULT_LEVEL: A balance between speed and size.
• NO_COMPRESSION: The file is added to a ZIP archive without being compressed. The data is stored as-is without undergoing any deflation.

Compression Method: The standard compression methods DEFLATED (the standard for ZIP files) and STORED (no compression) are available via the Compression.Method enum.

Note: Both the compression Level and Methods are available as enumerated data types within the namespace.

The namespace also contains three separate apex classes for reading and writing a zip file, namely:

• ZipEntry Class: Represents a single entry (a file or directory) within a ZIP archive and contains methods to access its metadata, such as its name and size.
• ZipReader Class: Used for reading and extracting files from a compressed ZIP archive within Apex.
• ZIPWriter Class: As the name suggests, this class is used for creating ZIP files within Apex, which can then be stored or sent as attachments.

public static void zipReader(){
        //Create a ZIPReader instance for working on zip files in Salesforce\
        //Zip Reader has a single constructor which accepts blob data
        
        //VersionData data type is blob
        ContentVersion compressedVersion = [SELECT Id,VersionData FROM ContentVersion where title = 'Test Compressed File'];
        Blob compressedBlob = compressedVersion.VersionData;
        
        //Initiate Zip Reader instance
        Compression.ZipReader zipReader = new Compression.ZipReader(compressedBlob);
        Map<String,Compression.ZipEntry> zipReaderMap = zipReader.getEntriesMap();
        
        //Iterate over ZipReader Map
        for(String fileName : zipReaderMap.keyset()){
            system.debug(fileName);
        }
    }

Handling Multiple Files within a ZIP

The Apex Compression Namespace offers powerful capabilities for managing multiple files inside a single ZIP archive directly within Salesforce. Using the Compression.ZipReader class and its methods — getEntries() and getEntriesMap() — developers can easily retrieve all ZIP entries in a structured and readable format.

Each Compression.ZipEntry object represents a file within the archive. After retrieving an entry, you can call the extract() method on the ZipReader instance to obtain its content as a Blob. This Blob can then be processed, stored as a new ContentVersion, or passed to other Apex routines according to your business requirements.

Understanding Governor Limits with the Compression Namespace

While the Compression Namespace introduces advanced new functionalities to Salesforce, it comes with constraint that applies to all of the Salesforce instances – Governor Limits.

Compression may reduce the final size of a file or payload, but it does not reduce the memory (heap space) consumed during the compression process—including loading the file and storing intermediate variables still counts toward the governor limits.

Key points to remember:

• In synchronous transactions, the heap size is limited to 6MB.
• In asynchronous contexts (like Queueable or Batch Apex), the limit increases to 12MB.

When dealing with large files, especially when converting them into a compressed format, it’s important to understand that reading the file into memory (e.g., as a Blob) and storing it in a variable consumes heap space before compression takes place. Simply compressing the file does not circumvent the governor limit; careful handling and memory management are still essential.

Use Cases of the Apex Compression Namespace

The Apex Compression Namespace can be used across several practical Salesforce file-compression scenarios. Here are some of the common implementation areas:

• When sending data through HTTP callouts, you can compress the request body to stay within strict size limits or improve network efficiency. This helps optimize integration performance and reduce API payload size.
• If an external system returns data in a compressed format, use the Compression.ZipReader class to unpack and process it directly within Apex—no external services required.
• In certain cases, email systems restrict or reject uncompressed file attachments. With the Apex Compression.ZipWriter class, you can create Apex ZIP files and send them as email attachments securely and efficiently, all within Salesforce.

These use cases demonstrate how the Compression Namespace enables end-to-end file compression workflows, from API communication to document management, while keeping logic and data entirely native to Salesforce.

Final Thoughts

The Apex Compression namespace in Spring ’25 is a welcome addition for Salesforce developers. It streamlines file management tasks like creating and reading ZIP archives with ZipReader and ZipWriter, enabling practical use cases like compressed API payloads and optimized email attachments.

However, the platform’s governor limits remain in play. Plan your memory usage carefully, favor asynchronous patterns for large files, and choose compression settings intentionally. Used wisely, this feature reduces reliance on external tools, speeds up development, and keeps your logic 100% on-platform.

Visit our Resource Center to explore more real-world integration patterns, expert tips, and implementation guides like this.