How Eazip works
Understand the two integration packages, Local and Cloud execution, and the job model they share.
Eazip separates how your application integrates from where the ZIP job runs. Choose each independently.
Choose an integration
| Your application | Package | Basic interface |
|---|---|---|
| React | @eazip/react | useEazip() and <EazipTray /> |
| Any browser application | @eazip/core | createZip() and startZip() |
Both packages accept the same input shapes and use the same job lifecycle. The React package adds state management and a ready-made download interface around Core.
Choose where the job runs
| Local | Cloud | |
|---|---|---|
| Runs in | The browser tab | Eazip Cloud |
| Sources | Browser files, blobs, and remote URLs | Remote URLs |
| Lifetime | Stops when the tab closes or reloads | Can survive a reload |
| Setup | None | Public key or backend-created session |
| Best for | Everyday downloads that fit comfortably in the tab | Multi-gigabyte archives, thousands of URLs, or resumable jobs |
Local is the default. Moving a URL job to Cloud changes its strategy, not the integration used by your application.
Start Local
Use Cloud when the job has a concrete scale, source-access, or persistence requirement. You do not need to decide up front.
Follow one job model
Every ZIP moves through the same basic flow:
- Your application supplies files or URLs.
- Eazip starts a job using the selected strategy.
- The job reports progress and reaches
completed,partial,failed, oraborted. - A completed or partial result exposes one or more ZIP downloads.
Use createZip() when you only need the finished result. Use startZip() when
you need progress or cancellation. useEazip() wraps the same model for React.
Continue from here
- Learn the
ZipJoblifecycle. - Understand inputs and remote sources.
- Decide when to use Eazip Cloud.