Home

react-native-blob-util

File system access, HTTP requests with file bodies and file downloads, and Android media storage for React Native, on Android, iOS and Windows.

This wiki explains how the 1.0 API works: what a request goes through, how a body is classified, where a response lives, how the streams behave, what rejects where. The per-call reference is the README; everything 1.0 changed is listed in Migration.md.

The API in one table

The API is grouped by what a call does, not by which platform implements it. A call a platform cannot make rejects with ENOTSUP.

Namespace	For	Reference
fetch, config	HTTP requests; config(options) returns a fetch bound to those options	Requests
fs	files, directories, streams, sessions, hashes, free space, well-known directories	File System
open	showing a file in another app, or letting the user pick one	Opening and picking files
media	Android's MediaStore, Downloads app and media scanner	Android media storage

import {fetch, config, fs, open, media, wrap, session, base64} from 'react-native-blob-util';
// or: import ReactNativeBlobUtil from 'react-native-blob-util'; the same objects.

How it works

• Default and named exports
• How a request works
• Request bodies
• The response
• Files and streams
• Platform support
• Errors
• Migrating from 0.x

Three rules that hold everywhere

• JavaScript decides what a request body is. Native obeys options.bodyType and infers nothing from a Content-Type or a prefix. See Request bodies.
• A content:// URI is never turned into a file path on Android. It is opened through its provider, or the call rejects ENOTSUP. See Platform support.
• A call resolves undefined unless it returns something the caller does not already have, and every rejection carries a code. A deprecated alias keeps resolving what it resolved before. See Errors.

Documentation for 0.x

The pages listed under 0.x (before 1.0) in the sidebar describe the API as it was up to 0.25, under the RNFetchBlob names. They are kept for apps that still run those versions.