React Native 0.82 Fetch Issues fetching local file
Description
When trying to fetch a file from the device and turn it into a blob with default fetch shipped within RN 0.82.0, fetch issues a TypeError. Also other methods to fetch the file from the device fail.
The code used for this:
const response = await fetch(image.path)
const blob = await response.blob()
Response:
Error: Uncaught (in promise, id: 1): "TypeError: Network request failed"
I used to used this throughout all RN versions I previously used and it doesnt work since upgrading from 0.73.6 to 0.82.0. If I implement it with the formdata approach that I find on multiple sources, the upload succeeds but I get corrupted files.
const formData = new FormData()
formData.append('file', {
type: mime.getType(image.path),
uri: image.path,
name: image.fileName,
});
If I use the XMLHttpRequest approach I get errors as well.
To me it seems something changed regarding to accessing files/uri's on a device, yet I find 0 sources on it. I changed all necessary permissions to match current latest approach.
I also added a reproducer with all 3 of the methods I described. You will need an endpoint to upload a file for the reproducer.
Does anybody know what I am doing wrong?
Steps to reproduce
- install packages
- start app
- supply an api url to the fetch methods
- pick an image
- press upload image
React Native Version
0.82.0
Affected Platforms
Runtime - Android
Output of npx @react-native-community/cli info
System:
OS: macOS 15.5
CPU: (8) arm64 Apple M2
Memory: 137.97 MB / 8.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 24.6.0
path: /Users/alexander/.nvm/versions/node/v24.6.0/bin/node
Yarn:
version: 1.22.22
path: /Users/alexander/.nvm/versions/node/v24.6.0/bin/yarn
npm:
version: 11.5.1
path: /Users/alexander/.nvm/versions/node/v24.6.0/bin/npm
Watchman:
version: 2024.04.01.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.14.3
path: /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 24.4
- iOS 18.4
- macOS 15.4
- tvOS 18.4
- visionOS 2.4
- watchOS 11.4
Android SDK:
API Levels:
- "31"
- "33"
- "34"
- "35"
- "36"
Build Tools:
- 30.0.3
- 33.0.0
- 33.0.1
- 34.0.0
- 35.0.0
- 36.0.0
System Images:
- android-34 | Google APIs ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: 2024.1 AI-241.18034.62.2411.12169540
Xcode:
version: 16.3/16E140
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.10
path: /usr/bin/javac
Ruby:
version: 2.6.10
path: /usr/bin/ruby
npmPackages:
"@react-native-community/cli":
installed: 20.0.0
wanted: 20.0.0
react:
installed: 19.1.1
wanted: 19.1.1
react-native:
installed: 0.82.0
wanted: 0.82.0
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: true
Stacktrace or Logs
Error: Uncaught (in promise, id: 1): "TypeError: Network request failed"
at onUnhandled (&platform=android&dev=true&lazy=true&minify=false&app=com.awesomeproject&modulesOnly=false&runModul…:22082:59)
at onUnhandled (address at InternalBytecode.js:1:3386)Caused by: TypeError: Network request failed
at anonymous (&platform=android&dev=true&lazy=true&minify=false&app=com.awesomeproject&modulesOnly=false&runModul…:24029:33)
MANDATORY Reproducer
https://github.com/IR-Baboon/reproducer
Screenshots and Videos
No response
Thanks for raising this! File URI handling changed in recent RN releases, so this may be caused by updated behavior in the new networking stack. Passing to the team for clarification on whether this is expected or a regression.
Thank you for responding and willing to look into this. I also fiddled around a bit and it seems the breaking change occurred somewhere between 0.81.0 and 0.82.0.
I made several test applications over a range of react native versions. 0.81.0 works. 0.82.0 doesnt work.
I cannot find anything in the changelogs regarding this breaking change. I will try a few minor releases in between to localize the exact breaking point.
I can confirm that in RN0.81.5 the approach using fetch is still working. The FormData approach gives a corrupt file while it worked in RN0.81.0.
For now I will downgrade to 0.81.5 until there is a possible solution.
Any solution?
I just reverted back to 0.81.5 for as long as there is no solution.
In version 0.83.0, the issue occurs on Android, but it works successfully on iOS.
https://github.com/facebook/react-native/releases/tag/v0.83.1 According to the changelog, this bug was fixed in version 0.83.1.
I can confirm this regression on React Native 0.82–0.83 on Android.
Overview
Since upgrading from RN 0.81.5 to 0.82+, network APIs (fetch, XMLHttpRequest) cannot correctly read local file:// URIs as Blob on Android — resulting in an empty Blob with status: 0 and _hasError: true. This breaks upload libraries that rely on Blob (e.g., tus‑js‑client).
Reproduction
Attempting:
function uriToBlob(uri) {
return new Promise((resolve, reject) => {
const xhr = new XMLHttpRequest();
xhr.responseType = "blob";
xhr.onload = () => resolve(xhr.response);
xhr.onerror = reject;
xhr.open("GET", uri);
xhr.send();
});
}
results in an empty blob and error-like state (status: 0, _hasError: true).
Not a permission issue
The file URI is valid and already accessible (e.g., from expo-document-picker).
No OS permissions errors are thrown.
The problem appears in how RN networking handles local URIs post‑0.81.
Related tus‑js‑client reports
This same error message (Error: tus: cannot fetch file.uri as Blob, make sure the uri is correct and accessible.) appears in tus‑js‑client issues where React Native users cannot upload files due to inability to fetch local URIs as Blob. GitHub
Example:
https://github.com/tus/tus‑js‑client/issues/284 — user reports this exact error in a React Native context, where tus fails because it cannot fetch the file URI. GitHub
Impact
Breaks tus‑js‑client and other Blob‑based upload logic.
Code that worked in RN 0.81.5 no longer functions without workarounds.
Requires people to rewrite upload logic (e.g., use expo-file‑system or backend proxies).
Questions
Is this change to how local URIs are handled in networking APIs intentional?
If not, can this regression be addressed or documented?
P.S. This also does not work in the new version of React Native (0.83.1).