Median Browser: a 215 KB local-first Android browser built on System WebView

The problem Median targets: browser data that leaves the device by default

Most Android browsers bundle an analytics SDK, a crash reporter and an account layer, then sync bookmarks and passwords to a server the user does not control. Median takes the opposite position. The README describes it as a local-first browser written in native Java on top of Android System WebView, with no advertising, analytics or crash-reporting SDK, and no developer-operated account or sync server. Bookmarks, history, passwords, user scripts and download records are stored on the device by default.

The audience is narrow and specific. It is for Android users who already understand what a WebView browser can and cannot do, and who would rather trade engine control for a small install and a short data path. The README puts the package at roughly 215 KB, against the tens to hundreds of megabytes typical of browsers that ship their own Chromium branch. That gap is the whole pitch: no bundled engine means the APK has almost nothing in it besides application code.

It is not aimed at teams that need a managed browser with policy enforcement, nor at users who expect cross-device tab handoff. The repository documents no server component at all, so there is nothing to sync through.

How Median is put together: WebView, request callbacks and local stores

The architecture diagram in the README shows MainActivity owning the browser UI and tabs, with System WebView as the rendering engine. Everything else hangs off those two. AdBlockEngine and MediaResourceSniffer attach to WebView, PasswordVault and UserScriptStore attach to the UI layer, and PerformanceMonitor and RendererWatchdog watch the renderer.

The ad blocker is described as an ABP and hosts-rule engine optimised for WebView request callbacks, with FilterSubscriptionStore managing online filter subscriptions that the user can add and update. That design choice matters: filtering happens in the request callback path rather than in a network proxy, so the engine sees what WebView asks for and nothing else. Element hiding, tracking-parameter stripping and per-site toggles are listed as part of the same module.

Passwords live in PasswordVault, which the README says uses Android Keystore keys with AES-GCM. CredentialAutofill is a separate script generator that handles multi-account and multi-step logins, Shadow DOM and same-origin iframes. PortableBackupCodec produces an encrypted portable backup with a user-supplied password and PBKDF2, so backups do not need a server.

Two modules are worth calling out because they are unusual in a WebView shell. MediaResourceSniffer is described as a bounded, read-only metadata index that parses HLS, DASH and Smooth Streaming manifests and reports tracks, resolution, bitrate, encryption and live or on-demand flags. TlsInspector runs a separate certificate probe on demand, showing the chain, cipher suite, issuer and validity, and the README states it does not listen in the background.

The privacy flow diagram is explicit that no developer server node exists. Requests go from the device to sites, search engines and filter subscription sources that the user chose. That is the honest framing: a browser still talks to the internet, and Median does not relay or intercept that traffic.

Building Median from source and taking a first look at the ad blocker

The README points to a build guide section rather than a published binary, and the repository root carries build.sh, build-update.sh, gradlew and gradlew.bat alongside a Gradle setup using AGP 8.13.2. The documented toolchain is Java 17, compileSdk and targetSdk 36, with a minimum of Android 8.0 (API 26). The applicationId is com.xinyv.median.compat and the namespace is com.xinyv.median.

The repository ships the Gradle wrapper at its root, and the README's build guide is the section that covers compiling the project. The wrapper scripts are the entry points the repository provides:

./gradlew

On Windows the same wrapper is invoked through the batch file:

./gradlew.bat

The repository also ships two shell scripts at the root for building and updating a build:

./build.sh

./build-update.sh

What you should end up with is an APK produced by the Gradle build. The repository does not publish a checksum or a signed release artifact, so the build is the distribution path unless you obtain a release elsewhere.

Once installed, the first real thing to try is the filter subscription list, because it is the module with the most visible effect. FilterSubscriptionStore manages online subscriptions that you add and update yourself. The README does not print the exact configuration keys for a subscription entry, so treat the in-app subscription screen as the interface rather than editing files by hand. After adding a source and reloading a page, the expectation is that matching requests are dropped in the WebView request callback and hidden elements disappear.

If you want to confirm the local-first claim before trusting it, the useful check is the password vault. Saving a login should prompt through CredentialAutofill, and PortableBackupCodec should refuse to export without a user-chosen password. Both behaviours are documented; neither requires network access.

Where Median stops being the right tool

The engine dependency is the biggest constraint. Median renders through Android System WebView, which means the browser's capabilities track the WebView version on the device, not the app's release cycle. The repository ships a WEBKIT_COMPATIBILITY.md and an AndroidX WebKit compatibility layer, which is an acknowledgement that OEM WebView builds differ. If a site breaks because of an old or vendor-modified WebView, Median cannot patch the engine. A browser with a bundled Chromium branch can.

Licensing is the second constraint, and it is not a formality. The README states plainly that the source is publicly readable but released under a source-available, all-rights-reserved licence, and that it is not open source in the MIT or GPL sense. The repository's LICENSE file is classified as NOASSERTION, and THIRD_PARTY_NOTICES.md exists alongside it. Anyone planning to fork, rebrand or redistribute needs to read both before doing anything, and the README itself directs readers to the licence section first.

The private window has a deliberate limitation that is easy to misread as a bug. The README says that when isolation cannot be guaranteed, the app does not pretend to be incognito. That is a design position, and it means the private window may refuse to behave the way users expect from other browsers rather than silently offering weaker isolation.

Finally, user scripts are third-party code with more privilege than a normal page. The README warns to install them only from trusted sources and notes that the engine validates explicit permission declarations and @connect targets. That validation reduces the blast radius; it does not make an arbitrary script safe.

Median against a bundled-engine browser such as Bromite-style Chromium forks

The natural comparison is a Chromium-based Android browser that strips telemetry and ships its own engine. The difference is not the privacy posture, which can be similar, but where the engine comes from and what that costs.

A Chromium fork carries its own renderer. That means a fixed, testable engine version, consistent behaviour across devices, and the ability to patch rendering bugs on your own schedule. It also means an install measured in tens of megabytes and a build pipeline that compiles a browser engine.

Median inverts every one of those. The install is around 215 KB because the engine is already on the device. Behaviour varies with the WebView version, and the project cannot fix engine-level bugs. The build is a Gradle Java project, not a Chromium checkout, which is why an individual developer can maintain it.

For a user on a recent Android device with an up-to-date WebView, the trade is favourable: small install, no telemetry, and features like the user script engine and the Keystore password vault that many lightweight browsers omit. For a user on an older or heavily modified device, or one who needs a specific engine version for a web app, the same trade works against them. There is also no iOS path, since the entire design rests on Android System WebView and Android Keystore.

Maintenance, releases and the licence question

The repository is not archived, and the last push was on 2026-09-04. Releases are frequent: 2.3.0 on 2026-08-14, 2.1.9 on 2026-07-17 and 1.4.0 on 2026-07-14. The numbering jumps around, which suggests the project does not follow a strict semantic scheme, and the README's version badge matches 2.3.0.

Upgrade cost is low for users, because there is no server-side migration to coordinate. The interesting upgrade surface is the encrypted data: PasswordVault and PortableBackupCodec both touch stored credentials, and a format change there would matter more than a UI change. The repository includes a CHANGELOG.md and a RELEASE_CHECKLIST.md, so release notes are the place to check before upgrading a device that holds saved passwords.

The licence is the item to settle before any distribution. The README calls it source-available with all rights reserved and explicitly says it is not MIT or GPL. The repository's LICENSE is unclassified by tooling (NOASSERTION), and THIRD_PARTY_NOTICES.md lists bundled components. This is not legal advice: read LICENSE and THIRD_PARTY_NOTICES.md yourself, and if you intend to ship Median inside a product, get your own review. For an individual installing it on a personal phone, the practical effect is that you may read and build the source but should not assume redistribution rights.

Editorial conclusion

Adopt Median if you want an Android browser whose bookmarks, history, passwords and scripts stay on the device, and you are willing to read LICENSE and THIRD_PARTY_NOTICES.md before redistributing anything, because the repository labels the licence Source Available rather than MIT or GPL. Do not adopt it if you need Play Store distribution, iOS, or a browser with a bundled Chromium engine you control, since Median renders through whatever System WebView the device ships. Verify first that your device is on Android 8.0 or later, that AndroidX WebKit behaves on your OEM build, and that the compat applicationId com.xinyv.median.compat matches what you intend to install.

Frequently asked questions

Official sources

1. bi-box/Median on GitHub
2. Issues
3. README
4. Releases