Fixing "Target Class [Controller] Does Not Exist" in Laravel

If you've just wired up a new route and hit a page full of red text reading something like:

Target class [App\Http\Controllers\UserController] does not exist.

...you're in good company. This is one of the most common errors Laravel developers run into, especially right after creating a new controller, renaming a class, or pulling a fresh clone of a project. The good news: it's almost always a quick fix once you know where to look.

This guide walks through every common cause, in the order you should actually check them, so you're not guessing.

What This Error Actually Means

Laravel's service container is trying to resolve a controller class by name, and it can't find a class matching that exact string — either because the class doesn't exist at that namespace, the autoloader hasn't registered it yet, or there's a typo somewhere between your route file and your controller file.

It's a resolution error, not a syntax error, which is why it can be confusing: your code will often look completely correct at a glance.

Cause 1: Autoload Files Are Stale

This is the single most common cause, especially after creating a new controller with php artisan make:controller or after pulling changes from version control.

Fix:

composer dump-autoload

This regenerates Composer's class map, which is what PHP uses to figure out which file a given class name lives in. If you skip this step after adding new classes, Laravel simply doesn't know the file exists yet.

Cause 2: Route and Cache Files Are Out of Sync

Laravel caches routes and config in production, and sometimes locally too if php artisan route:cache was run at some point. If you've changed a controller name or namespace since then, the cached version is now wrong.

Fix:

php artisan route:clear
php artisan config:clear
php artisan cache:clear

If you're on Laravel 8+ and use route caching in production, re-run php artisan route:cache after clearing, or your production routes will simply be empty until the next deploy.

Cause 3: Namespace Mismatch

This is the sneaky one. Your controller file might sit in the right folder but declare the wrong namespace at the top, or your route file might reference an old namespace that no longer matches.

Check the top of your controller file:

namespace App\Http\Controllers;

class UserController extends Controller
{
    // ...
}

And compare it against how you're referencing it in routes/web.php or routes/api.php:

use App\Http\Controllers\UserController;

Route::get('/users', [UserController::class, 'index']);

If the controller was moved into a subfolder (for example Controllers/Admin/UserController.php) but the namespace declaration wasn't updated to App\Http\Controllers\Admin, PSR-4 autoloading will fail silently until you hit this exact error.

Cause 4: File Location Doesn't Match PSR-4 Structure

Laravel relies on PSR-4 autoloading, which means the file path has to mirror the namespace exactly. App\Http\Controllers\Admin\UserController must live at app/Http/Controllers/Admin/UserController.php — not one folder off, not with a different casing on some operating systems.

If you moved or renamed a controller manually (outside of an IDE's refactor tool), this is worth double-checking line by line.

Cause 5: Typo in the Route Definition

Sometimes it really is this simple. A missing letter, a copy-pasted controller name from a different feature, or a stray autocomplete suggestion can all produce a class name that looks right but isn't. Read the exact class name in the error message character by character against your actual file name.

Quick Diagnostic Checklist

1. Run composer dump-autoload
2. Run php artisan route:clear && php artisan config:clear
3. Confirm the namespace declaration matches the folder path
4. Confirm the class name in the route file matches the class name in the file exactly
5. If using route caching in production, re-cache after confirming the fix

Nine times out of ten, steps 1 and 2 alone resolve it. The remaining cases almost always come down to a namespace or file path mismatch after a move or rename.

Frequently Asked Questions

Why does this error show up right after I create a new controller? Because the class doesn't exist in Composer's autoload map yet. Running php artisan make:controller creates the file, but the autoloader needs to be regenerated with composer dump-autoload before Laravel can resolve it.

I ran composer dump-autoload and it still doesn't work — what next? Clear the route and config cache next. If you previously ran route:cache, Laravel is serving routes from a compiled file that still references the old class path.

Does this happen in production but not locally? Yes, commonly. If your deploy process doesn't run composer dump-autoload --optimize and php artisan route:cache as part of the build, a class added or renamed since the last cache will trigger this error only on the server.

Is this related to the CSRF token mismatch error? No — different layer entirely. CSRF token mismatch happens during form submission and session validation, while this error happens when Laravel is trying to resolve which controller class to instantiate for a route. If you're troubleshooting both, treat them as separate issues.