ngx-cookie-service is a 1.3 kB cookie wrapper for modern Angular

A service, and a very small bundle

ngx-cookie-service is an Angular service to read, set and delete browser cookies, originally based on the ng2-cookies library. The service is lightweight, and its bundle size is 1.3 kB, with the stated reason being fast loading times and optimal performance.

That number is the whole pitch, and it is unusual for a library to lead with it. Angular's own cookie story is the platform document.cookie, which is a string, untyped, and returns nothing useful for writing since assignment is the only way to set a value. A service wrapper earns its place by fixing three things: it returns values, it takes options in a typed shape, and it works with the dependency injection system so a component asks for the service rather than reaching for a global.

The package is published on npm as ngx-cookie-service, and the repository carries a bundlephobia badge for the minified and zipped size, a build badge for the CI workflow, and a Discord and Gitter link for the community. The licence is MIT.

The maintenance picture is unusually disciplined for a small library. The releases are 22.0.1 from 2026-09-11, 22.0.0 from 2026-06-03 and 21.3.1 from 2026-03-15, and the version numbers track the Angular major version they support rather than being independent.

Installing, and the two ways to inject it

Installation is the usual two package managers:

npm i ngx-cookie-service

# or

yarn add ngx-cookie-service

The usage section shows two options, and the second one is the newer idiom. In standalone components you import the CookieService directly into the component:

   import { CookieService } from 'ngx-cookie-service';
   import { Component } from '@angular/core';

   @Component({
     selector: 'my-component',
     template: `<h1>Hello World</h1>`,
     providers: [CookieService],
   })
   export class HelloComponent {
     constructor(private cookieService: CookieService) {
       this.cookieService.set('token', 'Hello World');
       console.log(this.cookieService.get('token'));
     }
   }

You can also use the inject method in v14 and later:

   import { CookieService } from 'ngx-cookie-service';
   import { Component, inject } from '@angular/core';

   @Component({
     selector: 'my-component',
     template: `<h1>Hello World</h1>`,
     providers: [CookieService],
   })
   export class HelloComponent {
     cookieService = inject(CookieService);

     constructor() {
       this.cookieService.set('token', 'Hello World');
       console.log(this.cookieService.get('token'));
     }
   }

The difference is only where the reference lives. The first uses constructor parameter injection, the second assigns a field. Both list CookieService in the component's providers, so the service instance is scoped to that component rather than being a singleton for the whole application.

The API, and the rules it will not let you break

The surface is small. There is check, which returns a boolean for whether a cookie with the given name can be accessed or found:

const cookieExists: boolean = cookieService.check('test');

There is get, which returns the value of the cookie with the specified name:

const value: string = cookieService.get('test');

And getAll, which returns a map of key-value pairs for cookies that can be accessed:

const allCookies: {} = cookieService.getAll();

Then set, which has two signatures, one taking expires, path, domain, secure and sameSite as separate arguments, and one taking an options object with the same fields:

cookieService.set('test', 'Hello World');
cookieService.set('test', 'Hello World', { expires: 2, sameSite: 'Lax' });

Delete mirrors the set signature:

cookieService.delete('test');

Two of the behaviours are stated as important, and they are worth knowing before you write a test that surprises you. It is not possible to define cookies for other domains, because browsers do not allow it. And browsers do not accept cookies flagged sameSite as None if the secure flag is not set as well, so CookieService will override the secure flag to true if sameSite is None.

That override is the kind of detail that saves a debugging session. A cookie set with sameSite None and secure false will still be written, but it will be written as secure, and it will then be dropped over plain HTTP.

The version policy, which is the real constraint

The support policy is the part of this library that determines whether you can use it, and it is stated in one sentence. The project follows Angular's long term support versions. The latest version of the library supports Angular 22.x.x, and Angular 14.x.x or below is not supported.

The supported table covers the versions from 22.x.x down to 15.x.x, with each Angular version mapped to the matching supported version of the library. Angular 16, 17, 18, 19, 20, 21 and 22 are all covered, and 15 is the floor.

The consequence is that the library's version number is coupled to Angular's. A new Angular major release means a new major release of ngx-cookie-service, which is why the npm versions are 22.0.1 and 21.3.1 rather than a running 3.x or 2.x counter. For a team on a recent Angular this is convenient, because the upgrade path is the ordinary Angular upgrade, and for a team on an old Angular it is a hard stop.

The last push was on 2026-10-12, and the repository is not archived, so the Angular 22 line is being maintained. The repository also has a CHANGELOG, a SECURITY.md, a FUNDING.yml and an AGENTS.md, and the project is MIT licensed.

Server side rendering needs a different package

Ngx Cookie Service supports server side rendering via a dedicated library, ngx-cookie-service-ssr, and the documentation is emphatic about the install: only install ngx-cookie-service-ssr library, and skip ngx-cookie-service, for SSR.

       npm install ngx-cookie-service-ssr --save

       # or

       yarn add ngx-cookie-service-ssr

The reason is the one everybody hits. By default, browser cookies are not available in SSR because the document object is not available. To overcome this you edit the server.ts file in your SSR project, replacing the render call with one that also provides the REQUEST and RESPONSE objects:

server.get('*', (req, res) => {
  res.render(indexHtml, {
    req,
    providers: [
      { provide: APP_BASE_HREF, useValue: req.baseUrl },
      { provide: 'REQUEST', useValue: req },
      { provide: 'RESPONSE', useValue: res },
    ],
  });
});

That makes sure the cookies are available in the REQUEST object, so ngx-cookie-service-ssr can use REQUEST.cookies to access the cookies during SSR, and then you proceed to use ngx-cookie-service as usual.

The split is a good design, because the browser and the server are genuinely different environments, and a service that pretended otherwise would fail at the moment of rendering. The repository carries a server-example.ts at the top level, a netlify.toml and an angular.json, and the package scripts include a start:ssr target and separate build and test targets for the SSR demo.

The workspace, and how the package is built

The repository is an Angular workspace rather than a single library, and the manifest shows the shape of it.

The root package is private, and the scripts are the standard Angular CLI set with a twist. There is a build for the library, a build for the SSR package and a build for the SSR demo, a test for each, a lint for each, and an e2e script. The package script is the interesting one:

    "package": "ng build ngx-cookie-service --configuration=production && cp ./README.md ./dist/ngx-cookie-service && cd dist/ngx-cookie-service && npm pack",

So the published tarball is a production build with the README copied in, packed with npm pack, which is a clean way to guarantee the npm contents match the build output.

The dependency versions are pinned to the Angular 22 line, with @angular/cdk, @angular/ssr and @angular/platform-server all in the 22.2.2 range, rxjs at 7.8.2 and tslib at 2.8.1. The tooling is current too, with eslint 10, angular-eslint 22.6.0, @netlify/angular-runtime and the Netlify adapter for the SSR demo.

The projects directory holds the actual packages, the pnpm workspace file and pnpm-lock.yaml manage the monorepo, and there is a .browserslistrc, an .editorconfig, a .prettierrc and an eslint.config.js, so the formatting and linting rules are enforced rather than left to taste.

Editorial conclusion

Adopt ngx-cookie-service if you are on a supported Angular version and want a typed cookie service with no dependencies and a bundle you can measure. Do not adopt it on Angular 14 or older, because the current release drops those, and note that the SSR case needs a different package. Before you install, check three things: which Angular major version your application is on, since the supported table only covers 15 through 22, whether your rendering mode is server side, since that requires ngx-cookie-service-ssr instead of this package, and whether the sameSite behaviour matters to you, because the service will override the secure flag to true when sameSite is set to None.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. stevermeister/ngx-cookie-service on GitHub