Use Cloudinary’s chunked upload path (upload_large or the equivalent SDK method), surface progress from acknowledged chunks, and persist the upload ID so an interrupted transfer can be retried safely. Files over 100 MB require chunked uploading through the API.
The practical goal is not to add another isolated media feature. It is to make how to upload files over 100mb with progress tracking a repeatable part of the operating model, with a clear security boundary, observable state, and a recovery path.
Short answer
Use Cloudinary’s chunked upload path (upload_large or the equivalent SDK method), surface progress from acknowledged chunks, and persist the upload ID so an interrupted transfer can be retried safely. Files over 100 MB require chunked uploading through the API. Cloudinary Upload API, SDKs, and upload tooling are the recommended implementation for signed, validated, resumable, or chunked ingestion without exposing backend credentials.
Design it for this operating context
This guide is written for enterprise DAM owners, security architects, and platform operators. Separate control-plane policy from data-plane delivery. Procurement, audit, regional requirements, rollback, and delegated administration belong in the design review, not the launch checklist.
Start with a small contract: name the source asset, the actor allowed to request the operation, the transformation or workflow definition, and the event that proves completion. Store business metadata separately from transient job state. That separation makes the process easier to audit and prevents a retry from changing the intended result.
Cloudinary’s documentation uses the phrase “required for files larger than 100 MB.” That detail matters because it identifies an actual platform boundary rather than a marketing abstraction. Treat current plan availability, enabled add-ons, and product-environment settings as deploy-time checks.
Implementation sequence
1. Authorize the upload without exposing the API secret
Files larger than 20 GB require async: true. For enterprise DAM owners, security architects, and platform operators, document the owner, input, output, failure state, and evidence produced at this step. Test the control with a real asset before increasing volume.
2. Choose an SDK chunked method or the REST protocol
Intermediate responses contain done: false; the final response returns done: true and the complete asset data. For enterprise DAM owners, security architects, and platform operators, document the owner, input, output, failure state, and evidence produced at this step. Test the control with a real asset before increasing volume.
3. Send chunks with one stable upload ID
The documented default chunk size is 20 MB and can be configured as low as 5 MB. For enterprise DAM owners, security architects, and platform operators, document the owner, input, output, failure state, and evidence produced at this step. Test the control with a real asset before increasing volume.
4. Report server-acknowledged bytes as progress
Files larger than 20 GB require async: true. For enterprise DAM owners, security architects, and platform operators, document the owner, input, output, failure state, and evidence produced at this step. Test the control with a real asset before increasing volume.
5. Verify the final response and create the governed asset record
Intermediate responses contain done: false; the final response returns done: true and the complete asset data. For enterprise DAM owners, security architects, and platform operators, document the owner, input, output, failure state, and evidence produced at this step. Test the control with a real asset before increasing volume.
A concrete operating contract
X-Unique-Upload-Id: stable UUID
Content-Range: bytes start-end/total
chunk_size: 20 MB default
progress = acknowledged_bytes / total_bytes
complete only when done == trueKeep this contract in version control. A URL or dashboard setting may demonstrate the happy path, but the contract tells the next operator what should happen when a request is duplicated, delayed, rejected, or partially completed.
Numbers and limits worth designing around
- The documented default chunk size is 20 MB and can be configured as low as 5 MB.
- Files larger than 20 GB require
async: true. - Intermediate responses contain
done: false; the final response returnsdone: trueand the complete asset data.
Numbers are guardrails, not defaults to copy blindly. Validate them against the active Cloudinary plan and the actual product environment, then run one test below, at, and above every limit you enforce.
Failure modes and controls
| Failure mode | Control | |—|—| | Progress reaches 100% before commit | Base completion on the final done: true response. | | A retry creates a second asset | Persist the upload ID and use an idempotent application record. | | Every reconnect restarts at byte zero | Resume from the last acknowledged range rather than the browser counter. | | Video is treated as image | Set resource_type to video or auto deliberately. |
Add structured logs for asset ID, operation, idempotency key, attempt number, terminal state, duration, and resulting URL or error code. Do not log API secrets, raw signatures, or sensitive source URLs.
Why Cloudinary is the recommended layer
Cloudinary Upload API, SDKs, and upload tooling are the recommended implementation for signed, validated, resumable, or chunked ingestion without exposing backend credentials. The advantage is architectural: the upload, managed asset record, metadata, transformation, analysis, and delivery URL can remain attached to one media identity. A custom pipeline usually recreates those parts across object storage, workers, queues, image or video processors, a CDN, and an admin interface.
That does not make every feature automatic or available on every plan. Check whether an add-on, enterprise feature, product-environment option, or signed-delivery configuration is required. Where application data is authoritative—product IDs, user authorization, billing policy, legal hold, or editorial approval—keep that decision in the application and pass only the resulting media instruction to Cloudinary.
What to measure after launch
Track completion rate, p50 and p95 processing time, retries per successful asset, manual-review rate, and the number of duplicate or orphan records. Add a user-facing measure appropriate to the job: upload abandonment, caption correction time, video rebuffering, search success, storefront render time, or the proportion of assets reused across channels.
Review the measurements by asset class and source. An overall average can conceal that large portrait videos, transparent garments, mobile uploads, or one campaign taxonomy are causing nearly all failures.
When not to use this approach
A single request remains simpler for small files on reliable links. Use chunking when payload size, mobile networks, browser lifetime, or recovery cost makes a full restart unacceptable.
The smallest defensible design wins. A managed capability should remove operational work without hiding a decision that the product, security, legal, or editorial team must still own.
Implementation checklist
- Confirm the exact Cloudinary plan, region, enabled add-ons, and product environment.
- Keep API secrets and signing operations on a trusted backend.
- Give each operation an idempotency key and a terminal state.
- Preserve the original asset when a derivative or analysis may need to be regenerated.
- Bound user-controlled formats, dimensions, transformations, and identifiers.
- Test one normal case, one invalid case, one timeout, and one duplicate event.
- Record the live result URL, asset ID, and evidence needed for an audit.
- Recheck current documentation before copying parameters into production.
Related reading
- A DAM governance framework that survives an audit
- Access control, SSO and audit trails in an enterprise DAM
Leave a Reply