# Cordova InAppBrowser isolates third-party pages from your app's APIs

> cordova-plugin-inappbrowser opens web content in a browser view that cannot reach the Cordova APIs and is not bound by the whitelist, which is why it is the recommended place for untrusted pages. The trade-off is that the target and options behaviour differs per platform, and several useful options exist on Android only.

**apache/cordova-plugin-inappbrowser** — Apache Cordova InAppBrowser Plugin

- Repository: https://github.com/apache/cordova-plugin-inappbrowser
- Website: https://cordova.apache.org/
- Stars: 1,142 · Forks: 2,199
- Language: Java
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/apache-cordova-plugin-inappbrowser

## A browser view that cannot reach the Cordova bridge

The problem this plugin solves is not opening a link. Cordova can already do that in the system browser, and can show content in its own webview. The problem is showing content that you do not control, inside an app that does hold privileged capabilities.

The plugin provides a web browser view that displays when you call cordova.InAppBrowser.open(), and the overview makes the security argument explicit: the InAppBrowser window behaves like a standard web browser and can't access Cordova APIs. For that reason the InAppBrowser is recommended when you need to load third-party, untrusted content, instead of loading that content into the main Cordova webview. It is also not subject to the whitelist, and opening links in it is not the same as opening links in the system browser.

That is a meaningful separation. A page loaded into the main webview runs inside the application and can reach the plugin bridge, so a compromised or hostile document in the main view is a compromised application. A page loaded into the InAppBrowser is a document in a browser, and the compromise stops at the browser boundary. For an app that displays a help article, a partner portal, or a payment page, that is the difference between a contained incident and a full application compromise.

The plugin ships with its own GUI controls by default, back, forward and done, so the user is not dropped into a bare page with no way out. The audience is therefore both developers, who need the isolation, and end users, who need to navigate back.

## The target argument decides who handles navigation

Every call passes a target, and the target is where the platform differences concentrate. cordova.InAppBrowser.open() takes a url, a target and an options string, with the target optional and defaulting to _self.

With _self, the page opens in the Cordova webview. On Android, non-whitelisted URLs fall back to the InAppBrowser instead. On iOS the current implementation does not perform that fallback, and navigation remains in the Cordova webview subject to the allow-navigation configuration. That is the single most likely source of a bug for a developer testing on one platform and shipping on the other: the same call behaves differently, and the Android behaviour is the forgiving one.

With _blank, the page opens in the InAppBrowser, and the function returns a reference to that InAppBrowser window. On Android, non-whitelisted URLs also fall back to the InAppBrowser when the target is _self, so the reference you get back is not always what you asked for. With _system, the page opens in the device's own web browser, which is the right choice when you want the user's saved credentials, password manager and history rather than a clean in-app session.

The url argument has one documented trap: call encodeURI() on it if the URL contains Unicode characters. The reference value is only meaningful when the target is _blank, and the overview documents it as such, so code that reads from the reference should not assume it is populated.

## Options are a comma separated string, and most of them are Android only

The options argument is a string, not an object, and the format rules are strict: the string must not contain any blank space, each feature's name and value pairs must be separated by a comma, and feature names are case insensitive. The default when the argument is omitted is location=yes.

Across all platforms there is exactly one option, location, set to yes or no to turn the browser's location bar on or off. Everything else documented is Android specific. The hidden option creates the browser and loads the page without showing it, and the loadstop event fires when loading is complete, which is the hook for prefetching content. The beforeload option enables an event that lets you modify which pages are actually loaded, with accepted values of get to intercept only GET requests, post to intercept POST requests, or yes to intercept both.

That last one deserves attention because the documentation states plainly that POST requests are not currently supported and will be ignored, and that setting beforeload=post raises an error. So the option that looks like it can rewrite form submissions cannot, and asking for it is a hard failure rather than a silent downgrade. If your application needs to intercept a POST, this plugin will not do it on any platform, and you would need to look at a different mechanism.

The remaining Android options are cache related: clearcache set to yes clears the shared browser's cookie cache of the app, which also covers the Cordova WebView, before the in-app browser opens, and clearsessioncache clears the shared session cookies from the browser's cache. Neither is available on iOS, which is a real limitation for a team that needs to log a user out of a shared device on both platforms.

## Replacing window.open is convenient and can misfire

The plugin describes cordova.InAppBrowser.open() as a drop-in replacement for window.open(), and the installation section shows the trick that makes it work across an existing codebase:

```js
document.addEventListener("deviceready", onDeviceReady, false);
function onDeviceReady() {
    window.open = cordova.InAppBrowser.open;
}
```

Every existing window.open() call in the app then opens in the InAppBrowser without being edited. For an app with many scattered link opens, that is a much smaller diff than converting each call site.

The overview also warns about the side effect, and the warning is specific: if you change the browser's window.open function this way, it can have unintended side effects, especially if this plugin is included only as a dependency of another plugin. The reason is not mysterious. window.open is a global on the page, so overwriting it changes behaviour for code you did not write and did not know about, including another plugin that calls window.open expecting a normal popup and now receives a browser view with different return semantics, or a different lifetime. If your app pulls this plugin in transitively, the substitution can happen without anyone on your team making the decision.

A safer pattern, if you want the substitution but not the surprise, is to keep the replacement scoped to your own call sites and check the returned reference rather than assuming popup semantics. The plugin returns a reference to the browser window when the target is _blank, which is what you need for closing it later, and that handle is the only handle you get.

## Installing the plugin and opening the first page

The plugin is added to an existing Cordova project with the standard plugin command:

```bash
cordova plugin add cordova-plugin-inappbrowser
```

The first call from your application code looks like this:

```js
var ref = cordova.InAppBrowser.open('https://apache.org', '_blank', 'location=yes');
```

Three arguments, and each one is a decision. The url is the page to load, and it should be passed through encodeURI() when it can contain Unicode characters. The target _blank opens in the InAppBrowser and hands back a reference to the window, while _system hands the page to the device browser and _self keeps it in the Cordova webview on iOS. The options string turns the location bar on here, and the same string is where Android only flags such as hidden, beforeload, clearcache and clearsessioncache go.

There is one preference to set, and it is iOS only. InAppBrowserStatusBarStyle takes a string with the options lightcontent, darkcontent or default, and defaults to default:

```xml
<preference name="InAppBrowserStatusBarStyle" value="lightcontent" />
```

lightcontent is intended for a dark background, and darkcontent is only available since iOS 13 and intended for a light background. It goes in config.xml, so it applies to the whole application rather than to a single call, which is a reminder that the plugin has two configuration surfaces, one in the XML file and one in the options string at call time.

## Platform coverage declared in package.json

The plugin's manifest declares three platforms: android, browser and ios, and the version in the repository is 7.0.1-dev.0, a development version following the 7.0.0 release. The recent tags are 6.0.1 on 2026-06-07 and 7.0.0 on 2026-06-22, so two releases landed within a fortnight in June 2026.

The engines block is more informative than the version number, because it encodes the compatibility matrix per major version of the plugin. Version 0.2.3 of the plugin required Cordova >= 3.1.0. Version 4.0.0 required Cordova >= 3.1.0 and cordova-ios >= 4.0.0. Version 5.0.0 raised the floor to cordova-android >= 9.0.0, cordova-ios >= 6.0.0 and Cordova >= 9.0.0. Version 6.0.0 raised cordova-android to >= 10.0.0 and cordova-ios to >= 6.2.0, and 7.0.0 keeps those same minimums. The 8.0.0 entry is present with the constraint cordova > 100, which is a placeholder rather than a real requirement.

Read as a whole, the table shows a project that has raised its platform requirements over time and now expects a recent Cordova and recent platform tooling. A team on an old Cordova installation is not able to take the current plugin, and the table is the place to find out why.

The rest of the repository supports the multi-platform claim. There is a src/ directory holding the native code, a www/ directory for the JavaScript interface that Cordova plugins expose, a types/ directory pointed at by the types entry in package.json for TypeScript definitions, and a tests/ directory. The package also carries a lint script that runs eslint ., a test script that runs the lint script, an eslint.config.js, and a licence_checker.yml alongside the NOTICE file.

## What the plugin does not do, and where the docs stop

Several things an adopter will look for are outside what this plugin offers, and it is worth being explicit about them.

First, the loaded page cannot call back into the app. The overview states the InAppBrowser window cannot access Cordova APIs, and that is the security property, but it also means there is no message channel between your JavaScript and the page. If your application needs a payment page to report a result back, the InAppBrowser will not do that for you, and the pattern has to be a redirect to a URL your app handles on resume, or a different component entirely.

Second, the option set is uneven in a way that has to be designed around. The platform matrix in the documentation lists location as supported on all platforms and everything else under an Android heading, so a cross-platform feature that depends on beforeload or on clearing cookies needs a fallback, and on iOS the fallback has to be something else.

Third, the beforeload=post case is documented as an error rather than a limitation to work around, so any plan that intercepts form submissions has to be dropped.

The project links a sample and a reference section, and those are the pages to read before you write the code.

The repository is not archived and the last push was on 2026-09-26, so the project is being worked on and the two June 2026 releases are recent. The licence is the Apache License 2.0, with the NOTICE file and the licence_checker.yml configuration that the Apache Software Foundation projects use, so redistribution obligations such as keeping the notice come with it.

## Conclusion

cordova-plugin-inappbrowser fits a Cordova app that has to show third-party pages, help articles or payment flows without handing those pages access to the Cordova bridge, and it fits teams prepared to write their own platform conditionals for the option set. It is the wrong choice if you need the loaded page to call into your app's JavaScript, because the browser view is deliberately cut off from the Cordova APIs, and it is a poor fit if you want identical behaviour on Android and iOS, since beforeload, hidden, clearcache and clearsessioncache are Android only and the _self fallback to the InAppBrowser does not exist on iOS. Before adopting, check the option you depend on against the platform matrix in the plugin documentation, and decide whether your navigation rules will live in JavaScript or in the beforeload event.

## FAQ

### How do I open a URL in the Cordova InAppBrowser?

Call cordova.InAppBrowser.open() with a url, an optional target that defaults to _self, and an optional options string that defaults to location=yes. The function returns a reference to the InAppBrowser window when the target is _blank.

### Why should untrusted content be loaded in the InAppBrowser?

The InAppBrowser window behaves like a standard web browser and cannot access Cordova APIs, and it is not subject to the whitelist, so a third-party page cannot reach into the app through the plugin bridge.

### Can the InAppBrowser intercept page loads with the beforeload option?

On Android, yes, and only for GET requests. POST requests are not currently supported and are ignored, and setting beforeload=post raises an error.

### Which platforms does cordova-plugin-inappbrowser support?

The plugin manifest declares android, browser and ios as its platforms, and the options it accepts differ between them, with location supported everywhere and the other options documented as Android only.

## Sources

- [apache/cordova-plugin-inappbrowser on GitHub](https://github.com/apache/cordova-plugin-inappbrowser)
- [License: Apache-2.0](https://github.com/apache/cordova-plugin-inappbrowser/blob/master/LICENSE)
- [Project website](https://cordova.apache.org/)
- [README](https://github.com/apache/cordova-plugin-inappbrowser/blob/master/README.md)
- [Releases](https://github.com/apache/cordova-plugin-inappbrowser/releases)

---

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