They’ve all got their fans. A bigger influence on these stats is browsers that are pre-installed or built-in to operating systems. Chrome is default on Android. Safari is default on Apple-anything. Edge is default on Windows. Samsung Internet is default on Samsung phones. Firefox is default on some Linux distributions. People tend to leave defaults alone.

But what else is out there?

Let’s take a look at browsers with much less than 2% market share. They are based on the open source engines that power these other major browsers (except for a few we’ll mention at the end), but do unique things on top of those engines. It’s an interesting space to watch, as browser software is big business with how many potential users they are, so even niche audiences can build good businesses.

Heads up: Not all of these are particularly new, but hey, they might be new to you as some were new to me while poking around at this. I’ve focused here on desktop browsers, although many of them have mobile versions of themselves.

Arc

Arc is my personal daily driver. I really like it for a bunch of reasons. Turns out I really like the sidebar tab structure, multiple workspaces, split view, and the command bar to name a few. Arc did a great job of showing the world that real UI/UX innovation could happen around browsers while using an existing engine.

But Arc, while still getting updates for engine versions, is largely abandon-ware. I tried switching away (but failed). The company behind it is now working on another browser called Dia of which little is known aside from… more AI?

💰 Free (“Max”, the AI features used to cost money but not anymore?)

⚙️ Chromium

Horse Browser

The big thing with Horse Browser is that your tabs are in a sidebar and nested. They call that “Trails”. If that clicks with you, you’ll probably love it. If it doesn’t, there really isn’t any reason to use it.

💰 $60/year (7 day trial)

⚙️ Chromium

Zen Browser

Zen Browser is essentially a shameless replica of Arc, only free, open-source, and Firefox-based instead of Chrome. Hopefully they can keep up the momentum long term, find a business model, innovate beyond what Arc did, and find a way past the inability to stream stuff.

💰 Free

⚙️ Firefox

Orion

From the team at Kagi (the privacy-friendly search engine), this browser also has various privacy-friendly features. Like Horse, it’s going for that nested tabs in a sidebar thing, with new-window based tab groups. Another notable feature is that it supports Chrome and Firefox extensions as well as WebKit extensions — which seems entirely unique.

💰 Free

⚙️ WebKit

Vivaldi

Vivaldi seems to be able lots of features and lots of customizability. Put your tabs where ever you want them. Full on theming. There is integrated email, calendars, VPN, and even an RSS reader. With stuff like “command chains” and “mouse gestures”, this is power user focused.

💰 Free

⚙️ Chromium

Wavebox

It looks like the big play with Wavebox is that it uses big square icons for your tabs (“apps”) and you can group them together “just like your phone!” with notification badges and such. Then you have profiles you can switch between, so the drive is configuring your own job-specific home bases. Other features like “focus mode” and time tracking make is squarely a “this is for work” browser.

💰$100/year (7 day trial)

⚙️ Chromium

(Not to be confused with Wave browser which is weirdly similar?)

Surf

I haven’t been able to use their alpha, but from the video on their homepage, the UI looks a lot like Arc. It’s “context” instead of “workspace” and “stuff” instead of “library”. The AI feature where you ask questions based on the open stuff in your context seems straightforward and kinda smart. I like where it gets weird and you build your own sloppy homepage full of random rectangles.

💰Unknown

⚙️ Chromium? Probably?

Shift

Shift is definitely in the category of “browsers are for work, and work is apps, so here’s your apps.” Like many (most?) of these browser alternatives, it has workspaces, which means you can be logged into all those apps with your work accounts, switch workspaces, and be logged into all those same apps with different accounts (like a different client or your personal life or whatever).

💰$149/year (14-day trial)

⚙️ Chromium

Brave

Brave was launched in 2016 making it likely much older than most of these. It’s one of the big classic alternative browsers and has always been a bit controversial. It’s got a commitment to privacy, but isn’t fully open source and literally monetizes through ads. It’s got Brendan Eich at the helm who is controversial. It’s gotten into crypto stuff with Basic Attention Tokens, Brave Rewards, and Brave Wallet, and clearly not everyone is hyped on crypto. The UI is nicely polished and certainly has a lot of fans.

💰Free

⚙️ Chromium

DuckDuckGo Browser

DuckDuckGo itself is a privacy focused search engine using Bing’s search index. It seems the entire browser feature set is focused on privacy/protection and ad blocking (except their own).

💰Free

⚙️ WebKit on macOS / Blink on Windows

Opera GX

Of course there is Opera, which really used to be one of the main browsers, and sort of lost that distinction when it went Chromium sold and generally got weird (long story). Opera GX is “for gamers” which seems largely aesthetic, but hey, I can’t blame them. Seems like a niche worth serving.

💰Free

⚙️ Chromium

Colibri

The whole deal here is no tabs. Like forces you not to have tabs, so you’re doing “one thing at at time”. One of those things that’s either going to click with you or it isn’t. The “Links” feature is the additional thing to help you get back to things, which is… just bookmarks.

💰Free

⚙️ Chromium

Floorp

Customizability seems to be the main thrust here. Gestures, vertical tab bar option, and others.

💰Free

⚙️ Firefox

Muddy

Muddy is a multiplayer browser that lets you create shared views with your favorite apps. It’s the web, messaging, and intelligence for ambitious teams.

💰Free?

⚙️ Chromium, probably?

Min

Tabs in Min take up less space, giving you more room to browse the web. Pages you haven’t looked at in a while fade out, letting you see what’s important, and Focus Mode hides your other tabs to prevent you from getting distracted.

💰Free, Open Source

⚙️ Electron, so Chromium

Other Notable Entries

• Polypane isn’t intended to be a daily driver style of browser, but it is a browser that is designed for web developers and has tons of cool features specifically for that.
• If you’re specifically interesting in privacy-focused browsers where the feature set is largely “more privacy”, you’ve got:
  • LibreWolf
  • Waterfox
  • Iridium
  • Falkon
  • Epic Privacy Browser
• Mullvad, the VPN company, makes a browser because even they say “Using a VPN isn’t enough” if you want extreme privacy.
• Thorium is a Chromium browser specifically tweaked for speed. Related: ungoogled-chromium.

Very notable are the organizations trying to make entirely new browser engines, and browsers on top of them. Those are:

• Ladybird
• Flow
• Servo

Godspeed.

Well, Ladybird is giving it a go. They should have 7 full timers soon, and it’s open source so they’ll get help there, and are taking donations. Plus they’ll use some third-party resources to get it done, which should trim down on requirements. It reads like the thing already runs. Their big why is that Google is just too influential — and of course there is already controversy.

There is also Flow as well as Servo, which I’m told is the furthest along of all of them. They should get together on all this if you ask me. I’m happy to admit I was wrong and that it seems like new browser engines aren’t the fiction I thought they were.

While potentially convenient for mobile developers (i.e. users will never leave our app! the businessmen squeal), we’ll discuss the drawbacks for web developers like yourself and your users.

In-app browsers are also referred to as embedded browsers or WebView. These are interchangeable terms.

The Drawbacks

The drawbacks of in-app browsers can be broadly categorized:

• Limited functionality
• Privacy & security concerns
• Inconsistent UI/UX
• Worse performance

Limited functionality

In-app browsers are considerably stripped down when compared to their fully-featured counterparts and typically lack features like bookmarking, UI controls, settings, extensions, and downloads. For for instance a browser extension that a user depends on or help protect their privacy will not work in an in-app browser.

Privacy & security concerns

Because in-app browsers are embedded within a native mobile app, the app developer has control and visibility into the users’ in-app browsing activity. This even extends into being able to inject code into the in-app browser which is a major privacy and security concern. Users are largely unaware and aren’t able to opt-out even if they are.

Inconsistent UI/UX

Because in-app browser implementations are all different, the UI is inconsistent. Further, browsing data like history and bookmarks aren’t shared so users typically need to sign into services they may already be securely signed into in their devices actual browser. This leads to a fragmented and frustrating user experience.

Worse performance

In-app browsers tend to be running outdated browser internals which can cause slower loading times and compatibility issues. Users on slower Internet connections may have the problem exacerbated.

Author Update: Since Apple doesn’t allow apps, even browsers, to use their own rendering engine only Android has the problem of bundling in a custom in-app browser instead of using the system WebView, which may be outdated and have worse performance. On iOS, the built-in WebView is bundled as part of the iOS WebKit. On Android, the default built-in WebView is based on the Blink version and is updated independently of the OS as part of the Chrome update process via Google Play.

Bad Behavior in In-App Browsers

History

In-app browsers have existed since circa 2016, but it wasn’t until 2019 when Thomas Steiner, a Google engineer, published a blog post that dove into Facebook’s iOS and Android apps that a wider audience was made aware of the privacy and security concerns. Thomas discussed the technical details behind how the apps implemented their in-app browsers and stated how in-app browsers can perform man-in-the-middle (MITM) attacks by injecting arbitrary JavaScript code and intercepting network traffic.

Three years later, in 2022, Felix Krause published two blog posts (1, 2) and a tool, inappbrowser.com, which focused on the privacy concerns of iOS apps. Initially this covered apps by Meta (Facebook, Messenger, Instagram) and then followed up with Android and other social media apps including TikTok. Felix’s findings supported Thomas’ from 3 years earlier and showed concerning findings from iOS Instagram: the arbitrary injection of a pcm.js script which Meta claimed to be an “event aggregator” but was also monitoring user interactions in the form of taps and selections. Further cause for concern was TikTok injecting JavaScript that monitors all keyboard inputs along with taps, which is effectively the functionality of a keylogger on third-party sites. TikTok acknowledged the existence of this code but claimed it’s only used for debugging, troubleshooting, and performance monitoring.

Felix’s findings led to a lawsuit being filed against Meta in September 2022. The case was dismissed in October 2023.

Nothing Has Changed

Let’s revisit the behavior of iOS & Android Instagram’s in-app browser at the time of this writing (July 2024). This is done by sharing the two testing links, inappbrowser.com and inappdebugger.com (we’ll discuss this one more shortly), in the app as a direct message or URL in your profile bio. This is so you can actually click on them, as Instagram prevents clickable URLs in places like the descriptions of posts.

Let’s start with iOS. Below is iOS Instagram opening inappbrowser.com and inappdebugger.com in July 2024:

This shows that iOS Instagram is still injecting arbitrary JavaScript code which listens to user clicks along with JavaScript messages.

(Editor note: when testing this I noted that Instagram also appends URL parameters on outgoing links, which may be used to communicate additional information to this injected JavaScript).

Next, Android.

The story on Android is slightly different: there’s still arbitrary JavaScript being injected but it isn’t necessarily listening to events tightly coupled with user interactions.

Unfortunately, not much has changed since Felix’s findings nearly 3 years ago.

Open Web Advocacy wrote a piece earlier this year following the events of Apple threatening to kill web apps.

Debugging & Detecting In-App Browsers

Leveraging the existing excellent work of Felix Krause and Shalanah Dawson we have strategies for debugging and detecting when our websites are being viewed by in-app browsers.

• https://inappbrowser.com/
  • Attempts to detect if there’s any injected JavaScript code running.
• https://inappdebugger.com/
  • Attempts to detect you’re in an in-app browser and, if so, which app it is inside of.
  • Additionally provides some debugging tests for if downloads are possible and escape-hatches for getting to an actual device browser.
  • Leverages both inapp-spy and bowser.
• https://github.com/bowser-js/bowser
  • A browser detection library providing metadata and filtering based on browser version.
• https://github.com/shalanah/inapp-spy
  • A TypeScript library written by Shalanah Dawson that aids in detecting in-app browsers.

Escaping

Now that we have some tools, let’s look at a example in JavaScript for detecting and redirecting in Android using an intent: link. You’d do this if you simply do not want your website being opened in an in-app browser, and offer a link to users to open it in their default browser instead.

import InAppSpy from "inapp-spy"
const { isInApp } = InAppSpy()

// Your app's full URL, maybe defined build-time for different environments
const url = `https://example.com`
const intentLink = `intent:${url}#Intent;end`

// 1. Detect in-app
if (isInApp) {

  // 2. Attempt to auto-redirect
  window.location.replace(intentLink)
    
  // 3. Append a native <a> with the same intent link
  const $div = document.createElement("div")
  $div.innerHTML = `
    <p>Tap the button to open in your default browser</p>
    <a href="${intentLink}" target="_blank">Open</a>
  `
  document.body.appendChild($div)
}

It’s not ideal to have to load extra JavaScript for this, but it is reliable. This may be heavy handed, but for those of you working on particularly sensitive sites, it might be worth doing.

To get an idea of a way this can be implemented, Shalanah’s inappdebugger.com provides this functionality under the “Android In-App Escape Links” section.

Unfortunately, there’s currently no reliable way of handling iOS in-app browsers in terms of a proper escape hatch. Similar to Android, there’s a handful of device-specific URI schemes (that’s technically what the intent: prefix is called), but none of them are reliable to the default browser on a specific URL. A not-so-great workaround is using the x-web-search://? scheme, but the best-case is using the site: search prefix to get close to your actual URL e.g. x-web-search://?site:example.com.

Author Update: a somewhat reliable iOS workaround has been documented and tested by trying to run a Shortcut that doesn’t exist, specifying your URL in an error callback, and opening that in the user’s default browser. In practice, this looks like:

shortcuts://x-callback-url/run-shortcut?name=${crypto.randomUUID()}&x-error=${encodeURIComponent('https://example.com')}

This comes with some side effect caveats: the Shortcuts app is opened on the user’s device and some query parameters are appended to your URL. Read more on GitHub.

A last-ditch effort on iOS would be creating a UI element in your web app that gives the user manual instructions for bailing:

1. Tapping the “…” menu
2. Tapping on “Open in browser”

This is considerably more fragile and error-prone, but if you have the metrics to where your user traffic is coming from and which in-app browser is preventing them from converting to your feature-rich PWA then it could be worth considering.

Hopefully, with time, we’ll see the fall of in-app browsers. The privacy and security concerns alone are unacceptable. Couple that with the limited functionality and poor user experience, it’s probably best they just went away. Thanks to groups like the Open Web Advocacy and individuals like Shalanah Dawson and Felix Krause for their work and support for this cause.

Recommended Reading

• Shalanah Dawson
  • Talk: Solving the In-App Escape Room (This talk at JavaScript MN is what got me curious about all this.)
• Felix Krause
  • iOS Privacy: Instagram and Facebook can track anything you do on any website in their in-app browser
  • iOS Privacy: Announcing InAppBrowser.com – see what JavaScript commands get injected through an in-app browser
• Open Web Advocacy
  • In-App Browsers: The worst erosion of user choice you haven’t heard of
  • (PDF): Digital Markets Act – Interventions In-App Browsers
• The Meta in-app browser lawsuit
  • Initial lawsuit
  • Reply in support of dismissal
  • Dismissal

Of all Microsoft’s tactics, the most objectionable for me is their dissuasive messaging injected directly into the Chrome download page. As we write, ‘for a browser vendor to interfere with the contents of a competitor’s website – or indeed any website – with neither due cause nor user consent is highly irregular and ethically indefensible.’

We need to cry foul when browser vendors mess with the actual content on websites. While this just looks like two behemoths clashing heads, how would you feel about Microsoft making editorial choices on your website?

As web developers, we have very little power over the platforms we build on. We’re given what we’re given, we use what we get. We can say what we want, but it may or may not have any influence; there are lots of examples of both directions. We’re like armchair quarterbacks, cheering or jeering that over which we cannot control.

We also have lots of power, especially as a collective. We don’t have to use any particular features. We can do whatever we want. We don’t have to build websites at all. We generally want to use the web because it’s useful for a wide array of objectives, but they are always other means to an end. The web is meaningless without all the people who build sites and maintain them.

The companies that build the platforms are in the same boat. These companies have little power in what the entire industry does. They are at the whim of giant swings in user behavior and sentiment.

Those companies also have lots of power. They can do whatever they want with the platforms. They own them entirely. They make every decision.

Thus, this whole dance has to be symbiotic. There is a lot of incentive on both sides to keep dancing, so we will. But it’s still precarious. Either side can take their ball and go home.

Me, I’m optimistic. The web is very high up the list of the best things human beings have ever done, so let’s keep choosing it and making it better.