react-native-network-logger: an HTTP monitor with an in-app viewer and no native code

A network monitor that lives inside the app it monitors

react-native-network-logger is an HTTP traffic monitor for React Native including an in app interface. The README also positions it explicitly as an alternative to Wormholy, but for both iOS and Android and with zero native dependencies.

That last clause is the whole design. The usual approach to seeing network traffic from a React Native app on a device is a native module, because the native networking layer has to be hooked, and a native module means a podspec or a Gradle project, a rebuild, and a toolchain. This project intercepts in JavaScript instead, which is why the package advertises zero native or JavaScript dependencies and carries a dependencies-none badge.

The feature list tells you what the in-app interface does. It logs network requests on iOS and Android, and you can view network requests with an in app viewer. It can debug network requests on release builds, which is the case that motivates the whole library, since a release build is exactly where you cannot attach a proxy. You can individually view request and response headers and body, copy or share headers, body or the full request, and share a cURL representation of the request. There is an extraction of the GraphQL operation name, and export of all logs in HAR format.

The HAR export is the feature with the longest reach outside the app. A HAR file is a standard interchange format, so the log of a session on a device can be opened in a browser's network panel or in any tool that reads HAR, which turns a debugging session into something you can attach to a bug report.

The primary language is TypeScript, the licence is MIT, and the release history shows v3.0.0 from 2026-06-11, v2.0.1 from 2025-06-14 and v2.0.0 from 2025-05-11, with the last push on 2026-06-11.

Two calls to start logging and one component to render

The API surface is small, and the README shows the entire flow in three steps.

Installation is a normal package add, with yarn as the first option and npm as the alternative.

yarn add react-native-network-logger

npm install --save react-native-network-logger

Logging starts by calling startNetworkLogging in your app's entry point to log every request, or you can call it on a button press to manually trigger it. The entry point call is the interesting one, because that is what makes release build debugging possible, where the logger is running before anything else happens.

import { startNetworkLogging } from 'react-native-network-logger';

startNetworkLogging();
AppRegistry.registerComponent('App', () => App);

The viewer is a component you drop into a screen.

import NetworkLogger from 'react-native-network-logger';

const MyScreen = () => <NetworkLogger />;

That is the whole integration. There is no provider, no wrapper component to mount around the app, and no native registration step, which is what the zero native dependencies claim buys. The screen it goes on can be a debug-only route that is never reachable in a production build, or a hidden gesture, and the logging call can be made conditional.

The package.json confirms the packaging. The version is 3.0.0, the description calls it an HTTP traffic monitor for React Native with zero dependencies, the main entry points at the compiled module and the types entry at the generated declaration file, and the source field points at src/index.tsx. The published files are the lib and src directories, with the example, test, spec and fixture paths excluded. The build uses bob, and the scripts include a typescript check with tsc --noEmit, jest for tests, and a lint script that runs eslint and prettier.

Filtering, and the three ways to say leave this one out

The logging options are where a network monitor either becomes usable in a real app or becomes noise, and this one offers three separate filters.

The first is a cap on what is stored. You can configure the max number of requests stored on the device by calling startNetworkLogging with the maxRequests option, and the default is 500.

startNetworkLogging({ maxRequests: 500 });

That default matters more than it looks, because a monitor that keeps everything in memory on a device will eventually be the reason the app runs out of memory.

The next is hosts, with the ignoredHosts option, for a whole domain.

startNetworkLogging({ ignoredHosts: ['test.example.com'] });

The third is URLs, with the ignoredUrls option, for a specific path.

startNetworkLogging({ ignoredUrls: ['https://test.example.com/page'] });

And the third is patterns, with the ignoredPatterns option, which also covers methods. The pattern to match with is the method followed by the url, for example `GET http://example.com/test`, so you can match anything, for example ignoring all HEAD requests.

startNetworkLogging({
  // Ignore all HEAD requests
  ignoredPatterns: [/^HEAD /],
});

The method-prefix form is a small design decision with a large effect, because a regular expression over the method and the URL in one string is much more expressive than a list of URL globs. A developer can exclude every request to a telemetry endpoint with one pattern, or every request to a video host with another, without enumerating paths.

Presentation options, and one interceptor at a time

The viewer component takes a handful of presentation props, and one of them comes with an explicit warning.

There is a theme prop taking "dark" or "light", and you can also override the theme entirely by passing in a theme object. The note attached to that override is worth quoting in substance, because it is unusual: breaking theme changes are not guaranteed to follow semver for updates.

import NetworkLogger from 'react-native-network-logger';

const MyScreen = () => (
  <NetworkLogger
    theme={{
      colors: {
        background: 'red',
      },
    }}
  />
);

So a custom theme object is explicitly outside the versioning guarantee. A team that bakes a brand colour into the logger can find that colour replaced by a patch release.

The rest of the props are about making a long list usable. The sort prop sets the sort order of requests, with options of asc or desc and a default of desc, most recent at the top. The maxRows prop sets the maximum number of rows to display in the list to improve rendering, and the default is the same as the request limit. The compact prop makes the rows smaller to fit more on the screen.

import NetworkLogger from 'react-native-network-logger';

const MyScreen = () => <NetworkLogger sort="asc" />;

import NetworkLogger from 'react-native-network-logger';

const MyScreen = () => <NetworkLogger maxRows={100} />;

The one behavioural constraint worth planning around is the forceEnable option. If you are running another network logging interceptor, for example Reactotron, the logger will not start, because only one can be run at once, and forceEnable overrides that behaviour.

startNetworkLogging({ forceEnable: true });

For a developer running both a proxy-based tool and this in-app monitor, that conflict is the first thing to check when nothing appears.

Wiring the back button into an existing navigation stack

One integration detail is worth calling out because it decides where the viewer screen can live.

The README shows how to use your existing back button, for example in your navigation header, to navigate within the network logger. The library exports a getBackHandler alongside the default export, and you pass it the navigation goBack function.

import NetworkLogger, { getBackHandler } from 'react-native-network-logger';

const navigation = useNavigation();
const onBack = getBackHandler(navigation.goBack);

const MyScreen = () => (
  <Screen onBackPressed={onBack}>
    <NetworkLogger />
  </Screen>
);

The shape of this is the important part. The logger is a screen, and a screen needs a way back. Rather than requiring the logger to own a navigation stack of its own, it hands you a handler that you attach to whatever your app already uses, so the back gesture from the host navigation returns to the previous screen. That is what makes it possible to mount the logger on a screen inside an existing stack rather than in a modal of its own.

It also means the logger composes with a navigation library the project knows nothing about, which is the right constraint for a package that has no dependencies at all. The example app in the repository is where to see this in a working form, and the README documents that after cloning the repo, the required dependencies are installed by running yarn bootstrap, and then the example app is started.

What it is for, and the case where a proxy is still the better answer

The case this library wins is a bug that only reproduces on a device, on a build that is not a debug build, on a network you do not control. In that situation a laptop proxy is not an option, because the traffic never leaves the device in a form you can intercept from the outside, and a release build does not give you a native hook. An in-app monitor that intercepts in JavaScript works in exactly that situation, which is why the release build debug feature is the one the feature list leads with.

The case where it is the wrong tool is a development machine, where a proxy is better in every way. A proxy sees the traffic from outside the app, so it captures requests the app never makes through its own fetch wrapper, it works on a release build without modifying the bundle, and it gives you the traffic from several devices at once. The repository topics even include charles, which is a proxy, and the position of the library relative to a proxy is a design choice rather than an oversight.

There is a third consideration, and it is the one a team has to decide on purpose. This package intercepts HTTP in the application, in JavaScript, and the README's own list of features includes copying and sharing request bodies, headers and a cURL representation. Any application that ships this package ships an on-device view of its own traffic. That is harmless in a debug build, and it is a liability in a released one, where an exported HAR file or a shared cURL command may contain a bearer token, and where the interceptor itself is an attack surface. The library is MIT licensed and the logging is off unless startNetworkLogging is called, so the exposure is a matter of how you wire it rather than a defect, but it is the thing to think about before installing.

A fourth, smaller point. The feature set is HTTP only, and the request model is the one React Native's networking layer exposes. There is no mention of WebSocket frames, no mention of a background transfer, and the logger lives in the app, so anything that happens after the app is backgrounded or killed is not captured. For a diagnostic of a foreground flow, that is not a limitation. For a picture of all the traffic a background sync performs, it is.

Editorial conclusion

react-native-network-logger fits a developer who needs to see what a React Native app is actually sending on a real device, especially on a release build, and it does not fit an application that must not carry an HTTP interceptor in the shipped bundle. Before adopting it, check the forceEnable behaviour against whatever else in your app intercepts requests, because the README states only one interceptor can run at a time, and note that the theme override is explicitly excluded from semver guarantees, so a theme you write against can change without a major version bump.

Frequently asked questions

Official sources

1. alexbrazier/react-native-network-logger on GitHub
2. Issues
3. License: MIT
4. README
5. Releases