Eazip.js
EazipGitHub
Getting Started

How Eazip.js works

The two open-source packages, their browser-first job model, and the optional managed execution path.

Eazip.js separates how your application integrates from where the ZIP job runs. Local browser execution is the standalone default. If a URL-based job later outgrows the browser, the same SDK can connect it to Eazip without rewriting the interface.

Two packages, one engine

Your applicationPackageBasic interface
React@eazip/reactuseEazip() and <EazipTray />
Any browser application@eazip/corecreateZip() and startZip()

Both accept the same inputs and share one job lifecycle. The React package adds state management and a ready-made download tray around Core.

Two places a job can run

LocalCloud
Runs inThe browser tabEazip Cloud
SourcesBrowser files, blobs, and remote URLsRemote URLs
LifetimeStops when the tab closes or reloadsCan survive a reload
SetupNonePublic key or backend-created session
Best forEveryday downloads that fit comfortably in the tabMulti-gigabyte archives, thousands of URLs, or resumable jobs

Local is the default. Moving a job to Cloud changes its strategy option, not your integration.

Start Local

You do not need to decide up front. Use Cloud when a job has a concrete scale, source-access, or persistence requirement.

Which path fits your application — including backend-created sessions and the server-only HTTP API — is a separate decision, covered in Choose your integration path.

One job model

Every ZIP moves through the same flow:

  1. Your application supplies files or URLs.
  2. Eazip starts a job with the selected strategy.
  3. The job reports progress and ends completed, partial, failed, or aborted.
  4. A completed or partial result exposes one or more ZIP downloads.

createZip() waits for the finished result. startZip() exposes the running job for progress and cancel. useEazip() wraps the same model for React.

Continue from here