# ngx-device-detector: browser, OS and device detection as an Angular service
> ngx-device-detector is an Angular library that parses the user agent string and exposes the result as an injectable service with properties for browser, OS, device, user agent and OS version, plus helpers for mobile, tablet and desktop checks. It ships AOT compatible builds, supports Angular 7 through 22, and needs extra work to work under server-side rendering.
**AhsanAyaz/ngx-device-detector** — An Angular v7+ library to detect the device, OS, and browser details.
- Repository: https://github.com/AhsanAyaz/ngx-device-detector
- Website: https://ahsanayaz.github.io/ngx-device-detector
- Stars: 559 · Forks: 107
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ahsanayaz-ngx-device-detector
## User agent parsing, exposed as an Angular service
ngx-device-detector is described as an Angular 6+ powered AOT compatible device detector that helps to identify browser, os and other useful information regarding the device using the app. The processing is based on user-agent.
That last sentence is the whole design in three words, and it is worth being clear about because it determines both the strengths and the weaknesses of the library. There is no feature detection here, no capability probe, no measurement of what the browser actually supports. The library takes the user agent string that the browser sends and parses it into a structured result.
The service holds a small set of properties: browser, os, device, userAgent, os_version and isDesktopMode. The helpers are four booleans. isMobile returns whether the device is a mobile device, covering android, iPhone and windows-phone among others. isTablet returns whether the device is a tablet such as an iPad. isDesktop returns whether the app is running on a desktop browser. And isDesktopModeEnabled returns whether a mobile device is running in desktop mode, which the README describes as mobile browsers requesting desktop websites.
That last one is a nice touch, because it covers the case where the device is a phone or tablet but the browser asked for the desktop version of a site, which changes what layout you want to serve.
The AOT compatibility point is the one that matters for adoption. A library that does its work at runtime with reflection or with functions that cannot be statically analysed will break an ahead-of-time compiled build, and an Angular application from version 9 onwards is AOT by default. So this is a constraint the library had to satisfy, and the README leads with it.
The primary language is TypeScript, the licence is MIT with a LICENSE file at the root, the homepage is ahsanayaz.github.io/ngx-device-detector, and the last push was on 2026-06-08 with v12.0.0 tagged the same day, after v11.0.0 in December 2025 and v10.1.0 in August 2025.
## One major version per Angular major, and the table is the compatibility contract
The dependency table in the README is the thing to read before choosing a version, and it is unusually granular.
| ngx-device-detector | Angular |
| ------------------- | ------- |
| 1.3.3 | 7.x |
| 1.3.5 | 8.x |
| 1.4.1 | 9.x |
| 1.4.5 | 10.x |
| 2.0.5 | 11.x |
| 2.1.0 | 12.x |
| 3.x.x | 13.x |
| 4.x.x | 14.x |
| 5.x.x | 15.x |
| 6.x.x | 16.x |
| 7.x.x | 17.x |
| 8.x.x | 18.x |
| 9.x.x | 19.x |
| 10.x.x | 20.x |
| 11.x.x | 21.x |
| 12.x.x | 22.x |
Two things stand out. The first is that the library publishes a separate major line for each Angular major version, which is the standard way of handling the fact that Angular's own release cadence breaks libraries that depend on its internals. So your Angular version determines your ngx-device-detector major, and choosing the wrong one is not a small mistake.
The second is the age of the mapping. Angular 7 through 22 spans roughly seven years of framework releases, and the early entries have patch-level pins, 1.3.3 for Angular 7.x and 1.3.5 for Angular 8.x, which tells you that the early lines were maintained rather than abandoned partway.
There is a separate note about Angular 5 users: if you use Angular 5, you must use v1.5.2 or earlier. The table itself starts at Angular 7, so the Angular 5 case is handled by an older line that predates the table.
The package history is also visible in the README, and it is a naming story worth knowing if you are searching for the library. There is a deprecated package, ng2-device-detector, and a new package, ngx-device-detector, with download badges for both. The old name is the one people find first in a search, and it is the wrong one to install for a modern Angular application.
## Using it means injecting one service and calling a method
The usage section shows the whole integration in one component, and the shape of it is a standard Angular service injection.
```bash
$ npm install ngx-device-detector --save
```
```typescript
import { Component } from '@angular/core';
...
import { DeviceDetectorService } from 'ngx-device-detector';
...
@Component({
selector: 'home', //
styleUrls: [ './home.component.scss' ],
templateUrl: './home.component.html',
...
})
export class HomeComponent {
deviceInfo = null;
...
constructor(..., private http: Http, private deviceService: DeviceDetectorService) {
this.epicFunction();
}
...
epicFunction() {
console.log('hello `Home` component');
this.deviceInfo = this.deviceService.getDeviceInfo();
const isMobile = this.deviceService.isMobile();
const isTablet = this.deviceService.isTablet();
const isDesktopDevice = this.deviceService.isDesktop();
const isDesktopMode = this.deviceService.isDesktopModeEnabled();
console.log(this.deviceInfo);
console.log(isMobile); // returns if the device is a mobile device (android / iPhone / windows-phone etc)
console.log(isTablet); // returns if the device us a tablet (iPad etc)
console.log(isDesktopDevice); // returns if the app is running on a Desktop browser.
console.log(isDesktopMode); // returns if a mobile device is running in desktop mode
}
...
}
```
No provider registration is shown in the usage example, so the component-level injection is all the snippet relies on. The call pattern is getDeviceInfo for the whole parsed object and the four boolean helpers for the common cases.
The service also exposes a setter path, setDeviceInfo, which the SSR section uses to inject a user agent string manually. That method is the seam between the browser path and the server path, and knowing about it matters if you plan to render on the server.
The library was built at KoderLabs, and the README credits ng-device-detector by srfrnk as the work it is inspired by and based on. That lineage explains the API shape, since the original was a plain Angular library and this one keeps the same surface while adding the Angular version support matrix and the SSR story.
## Server-side rendering needs the user agent injected by hand
The SSR section is the part of the documentation that tells you what this library does not solve, and it is worth reading before you commit.
For SSR, you have to make sure that the User Agent is available for device detection, which means you will need to provide it manually. If you are using ExpressJS, the documented approach is to create a pair of injection tokens for the request and the response.
```typescript
import { InjectionToken } from '@angular/core';
import { Request, Response } from 'express';
export const REQUEST = new InjectionToken('REQUEST');
export const RESPONSE = new InjectionToken('RESPONSE');
```
Then you subclass the device service, and on the server you call setDeviceInfo with the user agent header from the request.
```typescript
import { Inject, Injectable, Optional, PLATFORM_ID } from '@angular/core';
import { REQUEST } from 'path/to/express.tokens';
import { Request } from 'express';
import { DeviceDetectorService } from 'ngx-device-detector';
import { isPlatformServer } from '@angular/common';
@Injectable()
export class UniversalDeviceDetectorService extends DeviceDetectorService {
constructor(@Inject(PLATFORM_ID) platformId: any, @Optional() @Inject(REQUEST) request: Request) {
super(platformId);
if (isPlatformServer(platformId)) {
super.setDeviceInfo((request.headers['user-agent'] as string) || '');
}
}
}
```
And then you register it in the server module by providing DeviceDetectorService with the subclass as the implementation.
```typescript
{
provide: DeviceDetectorService,
useClass: UniversalDeviceDetectorService
},
```
The mechanism is worth understanding. The service takes PLATFORM_ID in its constructor, so it knows whether it is running on the browser or the server, and on the server there is no navigator object to read a user agent from. The subclass bridges that by pulling the header out of the Express request and pushing it into the service with setDeviceInfo. The empty string fallback covers a request with no user agent header at all.
So the SSR cost is a small amount of wiring: two injection tokens, a subclass, and a provider override. If your application is an Angular Universal app and the device branch affects what is rendered on the first paint, this is the price of getting the device right server-side, and it is worth paying. If the branch only affects behaviour after hydration, the browser-side path works on its own.
## The build is an Angular CLI workspace with library and demo projects
The package manifest shows this is a full Angular CLI workspace rather than a small library, and that explains the script list.
The library is built with the production configuration of a named project.
```json
"build:lib": "ng build ngx-device-detector --configuration production",
"build:demo": "ng build demo --configuration production",
"build:ci": "ng build demo --base-href https://ahsanayaz.github.io/ngx-device-detector/demo/ --configuration production --output-hashing=all",
```
There is a separate demo application, and a CI build of that demo with a base href pointing at the GitHub Pages URL and output hashing on, which is what publishes the live demo the README links to.
The documentation is generated with compodoc rather than by hand, into a docs/ directory with a named theme, and there are watch and serve variants for local work. The lint script is ng lint, and the test script is ng test against the library project with watch turned off, which is the correct shape for a CI run.
The release automation is conventional and worth noting because it explains the CHANGE_LOG.md file the README points to. The changelog script runs conventional-changelog with the angular preset and writes into CHANGE_LOG.md, the readme and the changelog are copied into the built output directory before publishing, and the prerelease script chains the changelog, a prettier format pass over the library, the copies and the library build together.
The repository layout matches: an angular.json at the root, a projects/ directory holding the library and demo projects, scripts/, docs/, assets/, an eslint.config.mjs, a .prettierrc, a commitlint.config.js, and steps-to-release.md documenting the release procedure.
There is also a .travis.yml in the root, which is a leftover from an earlier CI setup alongside the GitHub Actions workflow the README badge points at. Seeing both is a small sign of a project that has been in the Angular ecosystem long enough to have migrated its CI.
## Where ngx-device-detector is the wrong tool
The first wrong-tool case is anything that needs a reliable answer rather than a probable one. User agent strings are self-reported, and modern browsers make user agent strings unreliable in a specific way: a desktop Chrome on macOS and an iPhone running Safari both claim to be capable of desktop-class rendering, and browsers deliberately lie. If you are choosing a layout, the browser's own signals are better: CSS media queries for viewport size, the pointer and hover media features for input type, and the client hints the browser sends when you ask for them. The user agent is the weakest of the available signals, and this library is a good wrapper around that weakest signal.
The second case is server-side rendering where the device decision affects the first paint, and the request header approach is not available to you. If you serve from an edge runtime that does not forward the user agent, or you deliberately strip it for privacy, then the service parses an empty string and returns nothing useful. The SSR pattern in the README is written for Node and Express specifically.
The third case is a project that has outgrown a single version line. Because the library ships a separate major per Angular major, and the mapping table runs from Angular 7 to Angular 22, a team that upgrades Angular has to upgrade the library in lockstep and re-verify the service API. That is the cost of the compatibility guarantee, and it is a recurring rather than one-off cost.
The fourth case is a non-Angular application. The library is an Angular service with an Angular provider model and a service that depends on PLATFORM_ID, so it is not usable outside Angular without rewriting the wrapper.
There is also the newer platform direction to weigh. Browser client hints, where the browser sends structured device information itself, are the direction the platform has taken, and they are not what this library reads. A greenfield application building for modern browsers may be better served by a client hints based approach than by a user agent parser, and this library is a solution to a problem the platform is partly solving on its own.
On maintenance, the pattern is a release per Angular major, with v12.0.0 on 2026-06-08, v11.0.0 in December 2025 and v10.1.0 in August 2025, and the last push on 2026-06-08. The library is maintained in step with the framework rather than independently, which is the correct cadence for the constraint it lives under.
On licence, MIT is the permissive grant with no copyleft obligation and no requirement to publish changes, so a device detection layer can be vendored, modified or dropped into a commercial product without a licensing review beyond noting the terms.
## Conclusion
ngx-device-detector suits an Angular team that needs a device or platform branch in the browser and wants it behind an injectable service rather than scattered user agent checks, since the service exposes the parsed properties and the boolean helpers directly. It does not suit an application that needs a reliable answer on the server, because the library parses the user agent string and therefore depends on the string being accurate, which it is not on a desktop browser that lies about the device. Before adopting, check the version table against your Angular major, since the package publishes a separate major line per platform release, and plan the SSR case up front, because under server-side rendering the user agent has to be read from the request and injected by hand.
## FAQ
### What is ngx-device-detector?
It is an Angular 6+ powered AOT compatible device detector that identifies the browser, OS and other device information from the user agent string, exposing the result through an injectable DeviceDetectorService with properties for browser, os, device, userAgent, os_version and isDesktopMode.
### How do I install ngx-device-detector?
Run npm install ngx-device-detector --save, then inject DeviceDetectorService into your component and call getDeviceInfo or the isMobile, isTablet, isDesktop and isDesktopModeEnabled helpers.
### Which Angular versions does ngx-device-detector support?
The README lists a separate major line for each Angular major, from 1.3.3 for Angular 7.x up to 12.x.x for Angular 22.x, with early versions pinned at patch level. If you use Angular 5, you must use v1.5.2 or earlier.
### How does ngx-device-detector work with server-side rendering?
Under SSR you have to provide the user agent manually, because there is no navigator to read it from. The documented pattern creates injection tokens for the Express request, subclasses DeviceDetectorService to call setDeviceInfo with the user-agent header when running on the server, and provides that subclass in the server module.
### What helper methods does the ngx-device-detector service expose?
isMobile returns whether the device is a mobile device such as android, iPhone or windows-phone, isTablet whether it is a tablet such as an iPad, isDesktop whether the app is running in a desktop browser, and isDesktopModeEnabled whether a mobile device is running in desktop mode.
### What license is ngx-device-detector released under?
The library is MIT licensed, with the LICENSE file at the root of the repository. The current release is v12.0.0, tagged on 2026-06-08, and the package is published on npm as ngx-device-detector, with the older ng2-device-detector package deprecated.
## Sources
- [AhsanAyaz/ngx-device-detector on GitHub](https://github.com/AhsanAyaz/ngx-device-detector)
- [License: MIT](https://github.com/AhsanAyaz/ngx-device-detector/blob/master/LICENSE)
- [Project website](https://ahsanayaz.github.io/ngx-device-detector)
- [README](https://github.com/AhsanAyaz/ngx-device-detector/blob/master/README.md)
- [Releases](https://github.com/AhsanAyaz/ngx-device-detector/releases)
---
Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ahsanayaz-ngx-device-detector