You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(file-transfer): Add Option for Direct File Download to Downloads Folder on Web #22
The downloadFile method in the Capacitor Filesystem plugin on the web platform currently writes the file to the IndexedDB instead of directly downloading it to the Downloads folder. This behavior was introduced as a fix to a previous issue (#1716) and was implemented in pull request #1724. However, there are use cases where the old behavior (downloading the file directly to the Downloads folder) is preferred. I propose that an option be added to the downloadFile method to allow developers to choose whether the file should be written to the IndexedDB or downloaded directly to the Downloads folder.
Platform(s)
Web
Preferred Solution
Add an optional parameter to the downloadFile method that determines where the file should be saved. If the parameter is set to true, the file should be written to the IndexedDB. If it's set to false, the file should be downloaded directly to the Downloads folder.
Alternatives
An alternative solution could be to create a separate method for downloading the file directly to the Downloads folder. This would keep the downloadFile method's behavior consistent across all platforms, while still providing developers with the flexibility to choose where the file should be saved on the web platform.
Additional Context
Currently, to achieve the old behavior, developers need to manually read the file from the IndexedDB, create a Blob from the file data, create an object URL from the Blob, and then create a hidden anchor element to trigger the download. This workaround is not ideal as it adds unnecessary complexity to the code.
This feature request aims to eliminate the need for this workaround by providing built-in support for downloading files directly to the Downloads folder on the web platform.
changed the title [-]feat(Filesystem): Add Option for Direct File Download to Downloads Folder on Web[/-][+]feat(file-transfer): Add Option for Direct File Download to Downloads Folder on Web[/+]on Sep 5, 2025
The new FileTransfer.downloadFile api should either support setting the recursive option, or check if the directory already exists before trying to download the file.
When using the new api by itself i get the Cannot create Root directory, switching to the old one creates the root directory successfully, then when switching back to the new one i get the Current directory does already exist error.
Activity
OS-pedrogustavobilro commentedon Sep 5, 2025
Transfered issue to this repo since filesystem's
downloadFileis deprecated in favor of this plugin.[-]feat(Filesystem): Add Option for Direct File Download to Downloads Folder on Web[/-][+]feat(file-transfer): Add Option for Direct File Download to Downloads Folder on Web[/+]brospars commentedon Oct 30, 2025
The web implementation does not seem to work at all when using the Filesystem uri:
works fine on ios and android but fails on web witht the following error:
I am not sure this makes sense for indexeddb : https://github.com/ionic-team/capacitor-file-transfer/blob/main/packages/capacitor-plugin/src/web.ts#L469-L476
mCassanoQuix commentedon Nov 11, 2025
I'm experiencing the same problem on web, either the
Cannot create Root directoryerror, or another error related to the directory already existing.With the now deprecated api, i had to use a workaround, first trying to download with the recursive:true option, then without:
The new
FileTransfer.downloadFileapi should either support setting the recursive option, or check if the directory already exists before trying to download the file.When using the new api by itself i get the
Cannot create Root directory, switching to the old one creates the root directory successfully, then when switching back to the new one i get theCurrent directory does already existerror.