NullInjectorError No Provider: Angular DI Fix

You've just wired up a service, injected it into a component, hit save, and the app dies with NullInjectorError: No provider for UserService. Nothing looks wrong: the class exists, the import path resolves, the constructor signature is clean. Yet Angular insists it has no idea how to build the thing you just wrote.

This error is dependency injection telling you the truth. Angular never constructs injected classes with new directly. It consults a hierarchy of injectors, each holding provider recipes, and walks upward until it finds one that knows your token. When every level shrugs, you get this error with the infamous R3InjectorError bracket chain naming each dependent that failed.

The standalone-component era added a fresh twist. Apps bootstrapped with bootstrapApplication have no AppModule, so providers live in app.config.ts or the bootstrap providers array. The classic HttpClientModule import becomes provideHttpClient(), and TestBed specs need provideHttpClientTesting(). Half the NullInjectorError reports you'll see today are migration fallout from this shift.

This guide covers the full picture: how the injector hierarchy resolves tokens, when to use providedIn root versus providers arrays, how standalone providers differ from NgModule wiring, why HttpClient is the most common victim, and how to configure TestBed so specs pass without touching working app code.

How Angular's Injector Hierarchy Actually Resolves Tokens

Angular never calls new on your services directly. When a component declares constructor(private svc: UserService), the framework asks the component's element injector for the UserService token. If that injector has no recipe, the request bubbles to the parent injector, then the module or standalone context injector, then the root injector, then the platform injector. The first recipe found wins, and only when every level misses do you see NullInjectorError.

This bubbling design is what makes providedIn: 'root' so powerful. The decorator registers the recipe with the root injector at build time, so every component in the app resolves the same shared instance without any module editing. Tree-shaking also benefits: if nothing injects the service, the compiler drops it from the bundle. You get a singleton and dead-code elimination from one line.

The bracket chain in R3InjectorError mirrors this walk. Standalone[CheckoutComponent] names the injector where resolution started, and each arrow names a dependent that needed the next token. Reading right-to-left shows the exact missing recipe. Most developers read left-to-right and blame the component, but the component is just the messenger. The fix always targets the rightmost token: register it where the failing subtree can see it, and everything left of the arrow resolves itself.

import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class UserService {
  private users = ['ana', 'ben', 'cy'];
  list(): string[] {
    return this.users;
  }
}

// user-list.component.ts
import { Component, OnInit } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-list',
  standalone: true,
  template: `<ul><li *ngFor="let u of users">{{ u }}</li></ul>`,
})
export class UserListComponent implements OnInit {
  users: string[] = [];
  constructor(private usersSvc: UserService) {}
  ngOnInit(): void {
    this.users = this.usersSvc.list();
  }
}

providedIn root vs providers Arrays: Picking One Owner

New Angular developers often register services in two places at once: providedIn: 'root' on the class plus an entry in some module's providers array. For eager modules this duplication is harmless because both point at the root injector. For lazy modules it silently forks the service: the lazy child injector builds its own instance, and state written through one route is invisible through another. Login works, then the header says logged out.

The rule is one owner per service. Shared state like auth, cart, and API clients belongs to the root injector via providedIn: 'root', with zero providers entries anywhere. Deliberately scoped state, like a wizard's draft data, belongs in the providers array of the component or lazy route that owns it. Document the scoping choice with a comment, because the next developer will otherwise hoist it to root during cleanup and reintroduce the bug in reverse.

Choosing wrong also affects bundle size and testability. Root-provided services tree-shake when unused and inject cleanly into any TestBed. Component-scoped services can't be injected outside their subtree, which makes cross-component tests awkward. When a NullInjectorError names your own service token, check for double registration before adding yet another providers entry. Removing the extra registration beats adding a third.

import { Injectable } from '@angular/core';

// Option A: root singleton, preferred for shared services.
@Injectable({ providedIn: 'root' })
export class CartService {
  items: string[] = [];
}

// Option B: scoped instance, one per component subtree.
import { Component } from '@angular/core';

@Component({
  selector: 'app-cart',
  standalone: true,
  providers: [CartService],
  template: `<p>{{ items.length }} items</p>`,
})
export class CartComponent {
  items: string[] = [];
  constructor(private cart: CartService) {}
  ngOnInit(): void {
    this.items = this.cart.items;
  }
}

// providedIn: 'root' needs NO entry in any providers array.
// Adding one in a lazy module forks a second instance.

Standalone Apps: provideHttpClient and importProvidersFrom

Standalone apps have no AppModule, so there is no imports array at the root that can carry provider registrations. Instead, bootstrapApplication takes a providers array, conventionally factored into app.config.ts. Functional providers like provideRouter() and provideHttpClient() register the same recipes that NgModules used to contribute, but they're tree-shakable: unused features never enter the bundle.

The migration trap is assuming old module imports still feed the root injector. A shared UI module that imports HttpClientModule registers that recipe in its own branch, not in the standalone bootstrap context. Your product page may work because it resolves through that branch, while checkout, served from a different branch, throws NullInjectorError for HttpClient. Both observations are true simultaneously, which is why the bug survives code review.

The bridge for half-migrated apps is importProvidersFrom(), which pulls an NgModule's providers into the standalone bootstrap context. Use it for third-party modules that haven't shipped functional providers yet, and prefer provideHttpClient() for first-party HTTP. Audit every module import you delete during migration: if the module registered providers, its deletion removes recipes, and each one needs a functional replacement in app.config.ts.

import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideHttpClient } from '@angular/common/http';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [provideRouter(routes), provideHttpClient()],
};

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';
import { appConfig } from './app/app.config';

bootstrapApplication(AppComponent, appConfig).catch((err) =>
  console.error(err),
);

// Legacy bridge when a module hasn't migrated yet:
// providers: [importProvidersFrom(OldModule)]

The Missing HttpClient Provider: DI's Most Common Victim

HttpClient is the most common NullInjectorError victim because its recipe never comes from your code. No decorator on your service can conjure it; only HttpClientModule in an NgModule imports array or provideHttpClient() in a standalone providers array registers it. Developers write a perfect root-provided service, inject HttpClient, and blame their own decorator when the real gap is the missing HTTP registration two files away.

The error chain gives it away: YourService -> HttpClient -> HttpClient ends in the framework token, not your class. That trailing repetition means Angular resolved your service fine and failed one level deeper. The fix never touches your service file. It touches app.module.ts or app.config.ts, which is exactly why the bug feels misplaced.

Prevention is a startup smoke test. A spec that injects HttpClient through your real appConfig fails the moment someone drops the registration, long before checkout breaks in production. Also centralize HTTP behind one or two root-provided API services instead of injecting HttpClient in twenty components. Fewer injection sites mean fewer chains to read, and interceptors attach in one place. When every request flows through a single service, a missing HttpClient provider breaks one obvious test instead of twenty mysterious components.

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

export interface Order {
  id: string;
  total: number;
}

@Injectable({ providedIn: 'root' })
export class CheckoutService {
  constructor(private http: HttpClient) {}
  placeOrder(order: Order): Observable<Order> {
    return this.http.post<Order>('/api/orders', order);
  }
}

// app.config.ts must include provideHttpClient()
// or this service throws: No provider for HttpClient.
// NgModule apps instead import HttpClientModule once in AppModule.

TestBed Injectors: Why Tests Fail When the App Works

TestBed builds a brand-new injector that inherits nothing from your app. A spec with an empty configureTestingModule has no HttpClient recipe, no router, and none of your root services unless you list them. The app can run perfectly while its specs fail with NullInjectorError, and the correct response is fixing the spec, not rewiring working app code.

For HTTP graphs the modern pair is provideHttpClient() plus provideHttpClientTesting(), which swaps the real backend for HttpTestingController. You assert requests with expectOne and flush fake responses, so specs never touch the network. The legacy equivalent is importing HttpClientTestingModule. Both approaches keep the testing injector shaped like the app injector without duplicating app.config.ts by hand.

For component specs, prefer NO_ERRORS_SCHEMA-free setups that declare the real dependency graph with mocks only at the boundary. Mock the service your component injects, not HttpClient three levels down: providers: [{ provide: CheckoutService, useValue: fakeService }]. This keeps specs fast and focused, and a NullInjectorError in the spec then points at the component's direct dependency instead of a framework token. Run the single spec file in isolation before editing anything; a green isolated run proves the failure was injector setup, not logic.

import { TestBed } from '@angular/core/testing';
import {
  provideHttpClient,
  provideHttpClientTesting,
  HttpTestingController,
} from '@angular/common/http/testing';
import { CheckoutService } from './checkout.service';

describe('CheckoutService', () => {
  let svc: CheckoutService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [provideHttpClient(), provideHttpClientTesting()],
    });
    svc = TestBed.inject(CheckoutService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => httpMock.verify());

  it('posts an order', () => {
    svc.placeOrder({ id: 'a1', total: 42 }).subscribe();
    const req = httpMock.expectOne('/api/orders');
    expect(req.request.method).toBe('POST');
    req.flush({ id: 'a1', total: 42 });
  });
});

Reading the Bracket Chain: R3InjectorError Token Paths

The R3InjectorError format looks hostile but parses mechanically. R3InjectorError(Standalone[CheckoutComponent]) names the injector where resolution started. Each bracketed segment TypeA -> TypeB means TypeA's constructor needed TypeB. The final NullInjectorError: No provider for HttpClient names the token nobody registered. Fix that token and the whole chain collaps to resolved.

Three chain shapes cover nearly everything. A chain ending in your own service means the service lacks providedIn or a providers entry. A chain ending in HttpClient, ActivatedRoute, or another framework token means a module import or functional provider is missing at the owning level. A chain naming a component token means you're injecting across element-injector branches, usually a sibling, and need to restructure with @Input() or a shared root service.

Build a team habit around chains: paste the full chain into the bug report, name the rightmost token explicitly, and state which injector level should own it. Reports written this way get fixed in one pass because the diagnosis is already half done. Reports that say only checkout is broken invite a week of guessing. The chain is the framework handing you the answer; reading it right-to-left is the whole skill.