# Chucker: an on-device HTTP inspector for Android and OkHttp

> Chucker is an OkHttp interceptor that stores request and response traffic inside your own app and shows it in an Android UI. It is a debug-build tool, and the release artifact is deliberately empty.

**ChuckerTeam/chucker** — 🔎 An HTTP inspector for Android & OkHTTP (like Charles but on device)

- Repository: https://github.com/ChuckerTeam/chucker
- Stars: 4,570 · Forks: 463
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/chuckerteam-chucker

## What Chucker replaces, and who it is for

Debugging HTTP on Android usually means routing traffic through a desktop proxy such as Charles, installing a CA certificate on the device, and keeping a laptop tethered to the same network. Chucker moves that inspection into the app itself. It is an OkHttp interceptor that persists HTTP(S) requests and responses inside your application and provides a UI for reading and sharing their content. The target reader is an Android developer already using OkHttp 4 who wants to see what the app actually sent and received, on the device, without a second machine in the loop. The README describes the project as a fork of Chuck, and it is distributed through Maven Central. Apps that use it display a notification summarizing ongoing HTTP activity; tapping that notification opens the full Chucker UI, and the README notes the notification can be suppressed so the app can launch the UI from its own interface instead.

## The interceptor, the collector, and where the data lives

The mechanism is an OkHttp interceptor plus a persistence layer. You build a ChuckerCollector with a context, a showNotification flag and a retention period, then build a ChuckerInterceptor from that collector and add it to the OkHttpClient. Every request that passes through the client is recorded by the interceptor and stored by the collector inside the app, which is why no external process or certificate is needed. The README gives a concrete retention control: RetentionManager.Period.ONE_HOUR. Two placement options exist, and they observe different things. The README's tip says to use addNetworkInterceptor instead of addInterceptor if you want the connected peer IP and everything OkHttp sends on the wire, including headers added by other network interceptors such as Content-Length, Accept-Encoding or cookies from a CookieJar. It also warns that the connected peer may be a proxy, VPN, CDN edge or load balancer rather than the origin server, and that cached responses do not pass through network interceptors. Application interceptors, by contrast, only see the request as your app builds it. That distinction matters more than most integration details: the same client will show you different headers depending on which method you call.

## Installing Chucker and inspecting your first request

Chucker is distributed through Maven Central. The README says to add the dependency to the build.gradle file of your Android app module, not the root file, and to add both the library and the library-no-op variant so release builds are isolated. The version shown in the README's snippet is 4.2.0; the most recent release listed in the repository is 4.3.1 from 2026-02-28.

```groovy
dependencies {
  debugImplementation "com.github.chuckerteam.chucker:library:4.2.0"
  releaseImplementation "com.github.chuckerteam.chucker:library-no-op:4.2.0"
}
```

The no-op artifact is what keeps Chucker out of your shipped APK. The README describes the release artifact as empty, with no traces of Chucker in the final APK. Next, plug the interceptor into your OkHttp client builder.

```kotlin
val client = OkHttpClient.Builder()
                .addInterceptor(ChuckerInterceptor(context))
                .build()
```

After that, the README states Chucker records all HTTP interactions made by your OkHttp client. Run the app, make a request, and expect a notification summarizing HTTP activity; tapping it opens the Chucker UI, where the recorded request and response appear. If you need the wire-level view instead, swap addInterceptor for addNetworkInterceptor, remembering that cached responses will not be captured that way. The README also notes older Chucker versions were distributed through JitPack.

## Configuring retention, redaction and body decoding

The default setup works, but the configuration surface is where the tool becomes usable on a real codebase. The ChuckerInterceptor.Builder takes a collector, a maxContentLength in bytes after which responses are truncated, a list of header names to replace with asterisks in the UI, an alwaysReadResponseBody flag, one or more body decoders, and a createShortcut flag. The README's example sets maxContentLength to 250000L and redacts Auth-Token and Bearer. The alwaysReadResponseBody option is the one worth understanding: the README says it reads the whole response body even when the client does not consume it completely, which it describes as useful for parsing errors or when the body is closed before being read, as happens in Retrofit with Void and Unit types. Decoders are applied in the order they were added. On redaction, the README carries a warning that stored data may contain sensitive information such as Authorization or Cookie headers and the contents of request and response bodies, and states the tool is intended for use during development, not in release builds or other production deployments. Redaction is a header-name filter, not a general scrubber for body content.

## Where Chucker is the wrong tool

Chucker only sees traffic that goes through the OkHttp client you modified. If your app uses a different HTTP stack, or a library that ships its own client you cannot reach, the interceptor never runs and the UI stays empty. The README also scopes the project to OkHttp 4 and API >= 21, so projects pinned to older OkHttp majors or lower minSdk are outside what the feature list claims. The README's own warning sets a harder boundary: this is a development tool, and the data it stores can include credentials and full bodies, so keeping it in a release build is not a supported configuration. Beyond that, the README does not document rollback, migration steps back to a plain client, or what happens to already-collected records when you change the retention period. It also does not describe how the records are stored on disk or how they are encrypted, so if your threat model includes someone reading app storage on a rooted or shared device, the documentation is silent on that point. Treat it as a debug aid, not as an audit log.

## Chucker against a desktop proxy such as Charles

Charles and similar proxies sit between the device and the network. They require certificate installation, a shared network, and a running desktop process, and in exchange they capture traffic from any app on the device, including ones you do not control. Chucker inverts that: nothing leaves the device, no certificate is installed, and the capture is limited to the OkHttp client you instrumented. The trade-off is scope. A proxy can show you a request from a third-party SDK or a WebView; Chucker cannot, because it is an interceptor inside your process. The README makes this comparison explicit in its own description, calling Chucker an HTTP inspector for Android and OkHttp, like Charles but on device. There is also a difference in what each side sees. The README's note about the connected peer being a proxy, VPN, CDN edge or load balancer applies to Chucker's network interceptor mode; a desktop proxy has its own view of the connection, and neither view is automatically the origin server.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-21. Releases are tagged rather than continuous: 4.3.1 on 2026-02-28, 4.3.0 on 2026-01-10, and 4.2.0 on 2025-07-12. That cadence suggests occasional upgrades rather than a stream of breaking changes, but the README's own dependency snippet still shows 4.2.0, so the documentation lags the newest release by one minor version. Upgrading means editing two Gradle lines, the debugImplementation and releaseImplementation entries, which is about as cheap as a dependency bump gets. The repository carries a CHANGELOG.md, and the README points readers to it for changes in the latest version; that file is the place to check before bumping. The licence is Apache-2.0, which is a permissive licence that generally allows commercial and closed-source use with attribution and notice requirements. That is a general description of the licence, not legal advice, and the LICENSE.txt file in the repository is the authoritative text. One practical cost to budget for is the no-op artifact discipline: if a release build ever picks up the real library instead, you ship an inspector and its stored data to users.

## Conclusion

Adopt Chucker if you ship an Android app on OkHttp 4 and want request and response bodies visible on the device without a proxy or a desktop machine, and if you are willing to wire the debug and no-op artifacts into your Gradle setup and keep Chucker out of release builds. Do not adopt it as a production monitoring or logging layer: the README states the stored data may contain Authorization or Cookie headers and body contents, and that it is intended for use during development, not in release builds or other production deployments. Before committing, verify two things in your own project: that your minSdk is at least 21, since the README lists API >= 21 compatibility, and that your OkHttp version is 4.x, since that is the version the feature list names. Then check whether your client consumes response bodies fully, because alwaysReadResponseBody exists for the Retrofit Void and Unit cases where it does not.

## FAQ

### What is Chucker in Android?

Chucker is an HTTP inspector for Android and OkHttp. It works as an OkHttp interceptor that persists HTTP(S) requests and responses inside your application and provides a UI for inspecting and sharing their content.

### How do you use Chucker to inspect network requests?

Add the library and library-no-op dependencies to your app module, build a ChuckerInterceptor from a context, and add it to your OkHttpClient.Builder with addInterceptor or addNetworkInterceptor. The README states Chucker then records all HTTP interactions made by that OkHttp client.

### What is Chucker network request inspection?

It is the capture of HTTP(S) requests and responses fired by your Android app through an OkHttp interceptor, stored on the device and shown in a Chucker UI, with a notification summarizing ongoing HTTP activity.

## Sources

- [ChuckerTeam/chucker on GitHub](https://github.com/ChuckerTeam/chucker)
- [Issues](https://github.com/ChuckerTeam/chucker/issues)
- [License: Apache-2.0](https://github.com/ChuckerTeam/chucker/blob/main/LICENSE)
- [README](https://github.com/ChuckerTeam/chucker/blob/main/README.md)
- [Releases](https://github.com/ChuckerTeam/chucker/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chuckerteam-chucker