Keeps the published surface of bowser@2.14.1 intact while adding a real ESM build, and rewrites CI so it can actually run the new toolchain. Packaging - Restore the flat artifact layout. es5.js and bundled.js stay at the tarball root next to src/, so unpkg.com/bowser/es5.js and require('bowser/bundled') keep working. bowser.mjs is added alongside. - Build the UMD bundles from dedicated single-default-export entries in build/entries/. src/bowser.js gained named exports (parse, getParser) to fix #511, but a UMD bundle with named exports makes require('bowser') a namespace object instead of the class: typeof flips from 'function' to 'object' and BROWSER_MAP / ENGINE_MAP / OS_MAP / PLATFORMS_MAP disappear, since they are static getters rather than exports. - globalName back to lowercase 'bowser', matching the shipped es5.js. Renaming it to 'Bowser' would break every script-tag consumer. - Enumerate every legacy subpath in the exports map. Conditional exports are honoured from Node 12.16.0 onward, so a "."-only map turns paths that resolve today into ERR_PACKAGE_PATH_NOT_EXPORTED. Subpath patterns ("./src/*") need Node 12.20.0+ and the trailing-slash folder form was removed in Node 17, so explicit per-file keys are the only spelling that works across the whole supported range. Extension-less aliases included: the README documents require('bowser/bundled'). - main, browser and module keep their existing values. No engines field (npm warns EBADENGINE, pnpm fails under engine-strict) and no type field (it would reclassify es5.js as ESM). Build - Minify the UMD bundles with terser instead of rolldown's built-in oxc minifier. oxc prints every string literal as a template literal and rejects any compress.target below es2015, so it cannot emit ES5 and was silently undoing babel's lowering. terser is what webpack 4 used. - Wire up the copyright banner, which was declared but never passed to a config, and restore bundled.js as the polyfilled build via core-js/stable. - Add index.d.mts so the import condition has ESM types. Reusing the export = declarations for both conditions describes an ES module with CommonJS types. CI - Replace npm ci with pnpm across all workflows. This is what was failing: the lockfile was swapped for pnpm-lock.yaml but the workflows still ran npm ci, pinned to Node 12.16.3 and 16. Build now runs on Node 24, which tsdown requires. - Add a pack-smoke job that installs the packed tarball on Node 12.16.3, 14, 18, 20 and 24 and exercises every documented entry point, plus publint and attw on the tarball. This is what makes "non-breaking" a tested claim rather than an argument; it catches all of the above. - Restore test-list-of-ua.js to asserting src against the built es5.js. It had been collapsed to comparing Bowser.parse with itself.
Bowser
A small, fast and rich-API browser/platform/engine detector for both browser and node.
- Small. Use plain ES5-version which is ~4.8kB gzipped.
- Optimized. Use only those parsers you need — it doesn't do useless work.
- Multi-platform. It's browser- and node-ready, so you can use it in any environment.
Don't hesitate to support the project on Github or OpenCollective if you like it ❤️ Also, contributors are always welcome!
Contents
Overview
The library is made to help to detect what browser your user has and gives you a convenient API to filter the users somehow depending on their browsers. Check it out on this page: https://bowser-js.github.io/bowser-online/.
⚠️ Version 2.0 breaking changes ⚠️
Version 2.0 has drastically changed the API. All available methods are on the docs page.
For legacy code, check out the 1.x branch and install it through npm install bowser@1.9.4.
Use cases
First of all, require the library. Bowser is a dual package: require resolves
to a UMD build (which also works for AMD and as a plain <script> tag), and
import resolves to a real ES module.
const Bowser = require("bowser"); // CommonJS
import * as Bowser from "bowser"; // TypeScript
import Bowser from "bowser"; // ES6 (and TypeScript with --esModuleInterop enabled)
The ES module build also exposes parse and getParser as named exports, so
you can import just the part you use and let your bundler drop the rest:
import { getParser, parse } from "bowser";
const browser = getParser(window.navigator.userAgent);
Loaded from a CDN or a <script> tag, Bowser attaches itself to the global as
bowser (lowercase):
<script src="https://unpkg.com/bowser@2/es5.js"></script>
<script>
console.log(bowser.parse(window.navigator.userAgent));
</script>
By default, the exported version is the ES5 transpiled version, which do not include any polyfills.
In case you don't use your own polyfills you may need to have pre-built bundle with all needed polyfills.
So, for you it's suitable to require bowser like this: require('bowser/bundled').
As the result, you get a ES5 version of bowser with core-js polyfills bundled together.
You may need to use the source files, so they will be available in the package as well.
Browser props detection
Often we need to pick users' browser properties such as the name, the version, the rendering engine and so on. Here is an example how to do it with Bowser:
const browser = Bowser.getParser(window.navigator.userAgent);
console.log(`The current browser name is "${browser.getBrowserName()}"`);
// The current browser name is "Internet Explorer"
Using User-Agent Client Hints
Modern browsers support User-Agent Client Hints, which provide a more privacy-friendly and structured way to access browser information. Bowser can use Client Hints data to improve browser detection accuracy.
// Pass Client Hints as the second parameter
const browser = Bowser.getParser(
window.navigator.userAgent,
window.navigator.userAgentData
);
console.log(`The current browser name is "${browser.getBrowserName()}"`);
// More accurate detection using Client Hints
Working with Client Hints
Bowser provides methods to access and query Client Hints data:
const browser = Bowser.getParser(
window.navigator.userAgent,
window.navigator.userAgentData
);
// Get the full Client Hints object
const hints = browser.getHints();
// Returns the ClientHints object or null if not provided
// Check if a specific brand exists
if (browser.hasBrand('Google Chrome')) {
console.log('This is Chrome!');
}
// Get the version of a specific brand
const chromeVersion = browser.getBrandVersion('Google Chrome');
console.log(`Chrome version: ${chromeVersion}`);
The Client Hints object structure:
{
brands: [
{ brand: 'Google Chrome', version: '131' },
{ brand: 'Chromium', version: '131' },
{ brand: 'Not_A Brand', version: '24' }
],
mobile: false,
platform: 'Windows',
platformVersion: '15.0.0',
architecture: 'x86',
model: '',
wow64: false
}
Note: Client Hints improve detection for browsers like DuckDuckGo and other Chromium-based browsers that may have similar User-Agent strings. When Client Hints are not provided, Bowser falls back to standard User-Agent string parsing.
or
const browser = Bowser.getParser(window.navigator.userAgent);
console.log(browser.getBrowser());
// outputs
{
name: "Internet Explorer"
version: "11.0"
}
or
console.log(Bowser.parse(window.navigator.userAgent));
// outputs
{
browser: {
name: "Internet Explorer"
version: "11.0"
},
os: {
name: "Windows"
version: "NT 6.3"
versionName: "8.1"
},
platform: {
type: "desktop"
},
engine: {
name: "Trident"
version: "7.0"
}
}
You can also use Bowser.parse() with Client Hints:
console.log(Bowser.parse(window.navigator.userAgent, window.navigator.userAgentData));
// Same output structure, but with enhanced detection from Client Hints
Filtering browsers
You could want to filter some particular browsers to provide any special support for them or make any workarounds. It could look like this:
const browser = Bowser.getParser(window.navigator.userAgent);
const isValidBrowser = browser.satisfies({
// declare browsers per OS
windows: {
"internet explorer": ">10",
},
macos: {
safari: ">10.1"
},
// per platform (mobile, desktop or tablet)
mobile: {
safari: '>=9',
'android browser': '>3.10'
},
// or in general
chrome: "~20.1.1432",
firefox: ">31",
opera: ">=22",
// also supports equality operator
chrome: "=20.1.1432", // will match particular build only
// and loose-equality operator
chrome: "~20", // will match any 20.* sub-version
chrome: "~20.1" // will match any 20.1.* sub-version (20.1.19 as well as 20.1.12.42-alpha.1)
});
Settings for any particular OS or platform has more priority and redefines settings of standalone browsers. Thus, you can define OS or platform specific rules and they will have more priority in the end.
More of API and possibilities you will find in the docs folder.
Browser names for .satisfies()
By default you are supposed to use the full browser name for .satisfies.
But, there's a short way to define a browser using short aliases. The full
list of aliases can be found in the file.
Similar Projects
- Kong - A C# port of Bowser.
Contributors
Code Contributors
This project exists thanks to all the people who contribute. [Contribute].
Financial Contributors
Become a financial contributor and help us sustain our community. [Contribute]
Individuals
Organizations
Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]
License
Licensed as MIT. All rights not explicitly granted in the MIT license are reserved. See the included LICENSE file for more details.