Direct-to-S3 / Azure tus 1.0 resume IndexedDB Golden Retriever 30 locales Webcam & screen capture

IndexedDB-backed resume

Every in-flight upload persists to IndexedDB automatically. With persistBlobs: true, File objects are stored too - uploads auto-resume after tab crashes or page reloads without re-picking files. Works with chunked, s3, and tus strategies: each resume preserves the server session (chunk offsets, S3 part ETags, or tus URL) so the resumed task continues from exactly where it stopped.

What you should see: start a chunked upload, reload the page mid-flight, and it resumes from the last completed 1 MB chunk instead of restarting. State is held in IndexedDB and verified against the server before resuming.
Drag & drop files here, or paste from clipboard
Try it: pick a large file, start uploading, reload the page (F5) before it finishes. The task auto-rehydrates from IndexedDB and continues from the last completed chunk.

Configuration

CoreUpload.create('#uploader', {
 uploadUrl: '/api/upload/upload',
 chunkUrl: '/api/upload/chunk',
 chunked: true,
 persistState: true,
 persistAdapter: 'indexeddb', // or 'localStorage' persistBlobs: true // store File blobs for zero-click resume
});

Rehydrate on load

uploader.on('stateRestored', function (state) {
 state.resumableTasks.forEach(function (entry) {
 // entry.blob present when persistBlobs=true; else pass a re-picked File: uploader.resumeFromState(entry /* , file */);
 });
});

What gets persisted

  • Always: task id, file metadata, strategy, progress, hash, per-chunk byte counts, S3 uploadId + part ETags, tus session URL.
  • With persistBlobs: true: the File object itself (IndexedDB stores Blobs natively).
  • Never: upload tokens with limited lifetimes - those are re-fetched on resume.

Storage limits

Browsers give IndexedDB 50-80% of available disk (Chrome, Firefox, Safari). Large batches with persistBlobs: true stay well within quota for most use-cases; for exceptional loads, set persistBlobs: false and prompt the user to re-pick on resume.