How to Fix 'No Provider for HttpClient' in Angular

By the end of this page, you will understand how Angular dependency injection provides HttpClient, why importing HttpClientModule in the correct module matters, and how build issues such as incorrect import casing can still cause the "No provider for HttpClient" error even when your code looks correct.

Angular uses dependency injection (DI) to create objects such as services. HttpClient is not something Angular creates automatically by magic. It becomes available only when Angular sees the provider setup from HttpClientModule.

When you write code like this:

constructor(private http: HttpClient) {}

Angular checks its injector and asks:

• Do I know how to create HttpClient?
• Was the module that provides it imported?
• Am I in the right injector scope?

If the answer is no, Angular throws:

NullInjectorError: No provider for HttpClient!

Why this matters

This is a core Angular concept, not just an HTTP issue. The same pattern applies to many Angular features:

• forms modules provide form directives
• router modules provide routing services
• HTTP modules provide HttpClient
• feature modules can have their own providers

So the real lesson is:

• Angular features often require module imports
• services are resolved through dependency injection
• wrong imports, wrong module scope, or duplicated builds can break DI

Think of Angular's injector as a tool cabinet.

• HttpClient is a tool you want to use.
• HttpClientModule is the instruction that tells Angular to put that tool in the cabinet.
• Your component or service asks for the tool.

If the tool was never added to the cabinet, Angular says:

• No provider for HttpClient

Now imagine you accidentally label one shelf as common and another as Common. On some systems those may be treated differently. You may think the tool is in the cabinet, but Angular is looking in one shelf while the tool was registered in another. That is why inconsistent import casing can produce confusing dependency injection errors.

The core syntax for using HttpClient is:

import { HttpClientModule } from '@angular/common/http';
import { HttpClient } from '@angular/common/http';

And in your root module:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { HttpClientModule } from '@angular/common/http';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, HttpClientModule],
  bootstrap: [AppComponent]
})
export class AppModule {}

Then in a service:

Consider this small example:

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

@Injectable()
export class ProductService {
  constructor(private http: HttpClient) {}
}

And this module:

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

@NgModule({
  imports: [BrowserModule]
})
export class AppModule {}

What happens step by step

1. Angular starts the application with AppModule.
2. Angular reads the imports array.
3. is registered.

Dependency injection and module-provided services appear everywhere in Angular apps.

API services

Most applications wrap HttpClient in services:

this.http.get('/api/orders')
this.http.post('/api/login', credentials)

If HttpClientModule is missing, all API communication fails.

Feature modules

Large apps split code into modules such as:

• AdminModule
• UserModule
• SharedModule

If services are declared and used across these modules, understanding where providers come from becomes essential.

Testing

In tests, developers often replace HttpClientModule with HttpClientTestingModule so requests can be mocked safely.

Migration work

When upgrading Angular versions, teams often move from old APIs to new ones. During migrations, mixed imports such as Http + are common sources of errors.

In real Angular codebases, developers usually handle this concept through a few common patterns.

1. Import framework modules only once in the correct place

Usually, root-level framework modules are imported in AppModule:

imports: [BrowserModule, HttpClientModule, AppRoutingModule]

This makes shared infrastructure available app-wide.

2. Keep HTTP logic inside services

Instead of making HTTP calls in components, developers write services:

@Injectable()
export class NotificationService {
  constructor(private http: HttpClient) {}

  load() {
    return this.http.get('/api/notifications');
  }
}

This keeps components simpler and easier to test.

3. Use guard clauses and validation around responses

A service might validate parameters before making requests:

() {
   (!id) {
      ();
  }

   ..();
}

1. Importing HttpModule but injecting HttpClient

Broken code:

import { HttpModule } from '@angular/http';
import { HttpClient } from '@angular/common/http';

Why it fails:

• HttpModule provides the old Http
• it does not provide HttpClient

Fix:

import { HttpClientModule } from '@angular/common/http';

2. Importing HttpClientModule in the wrong module

If the app bootstraps AppModule but you imported HttpClientModule somewhere else that is never loaded, Angular still will not find the provider.

Fix:

• import it in the module that is actually used

// New Angular HTTP API
import { HttpClientModule } from '@angular/common/http';
import { HttpClient } from '@angular/common/http';

// Old Angular HTTP API
import { HttpModule } from '@angular/http';
import { Http } from '@angular/http';

Rules

• If you inject HttpClient, import HttpClientModule
• HttpModule does not provide HttpClient
• Use exact lowercase package paths like @angular/common/http
• Avoid mixing Http and HttpClient unless you are migrating carefully
• In custom Webpack setups, rebuild vendor bundles after Angular upgrades

Quick fix checklist

• Check AppModule imports
• Search project for @angular/Common or other wrong casing

Why do I get "No provider for HttpClient" even though I imported HttpClientModule?

Usually because the module import is in the wrong place, the wrong module is being bootstrapped, or the build has duplicated Angular packages due to path or casing issues.

Does HttpModule provide HttpClient?

No. HttpModule provides the older Http service. HttpClient requires HttpClientModule.

Can incorrect import casing really cause Angular DI errors?

Yes. With some build tools, @angular/Common and @angular/common can be treated as different module paths, leading to duplicate module instances and missing providers.

Should I keep both HttpModule and HttpClientModule during migration?

Only temporarily if some code still uses the old Http service. But new code should use HttpClient, and old imports should be removed as migration finishes.

Should I add HttpClient to the providers array manually?

• Angular dependency injection — HttpClient is resolved through Angular's injector.
• NgModule imports — Angular modules register providers and features.
• HttpClient — the modern Angular service for HTTP requests.
• HttpClientModule — the module that provides HttpClient.
• HttpModule — the older Angular HTTP module, often seen in legacy code.
• Angular services — HttpClient is commonly injected into services.
• Lazy-loaded modules — provider scope and module boundaries matter in larger apps.
• Webpack module resolution — build tools can behave differently when paths or casing are inconsistent.
• Case-sensitive imports — incorrect casing can cause duplicate modules or build warnings.
• Angular migration — moving from old APIs to newer ones often exposes DI mistakes.