You submit a form, hit a POST endpoint, or send an AJAX request, and Laravel slaps you with a blank white page that just says "419 | Page Expired". No stack trace. No helpful message. Just that. If you've seen this, you know how frustrating it is, especially when the form looked perfectly fine a minute ago.
The http 419 laravel error is Laravel's custom status code for a CSRF token failure. It's not a standard HTTP status, so you won't find it in an RFC. Laravel invented it to mean one specific thing: the request arrived without a valid cross-site request forgery token, or the token it did carry has expired. Understanding that root cause makes every fix obvious.
What Is CSRF and Why Does Laravel Enforce It So Hard?
CSRF (Cross-Site Request Forgery) is an attack where a malicious site tricks a logged-in user's browser into making a request to your app without the user's knowledge. The classic example is a hidden form on attacker.com that POSTs to yourapp.com/transfer-money. Because the browser sends cookies automatically, your server has no way to know the request didn't come from your own UI, unless you use a secret token.
Laravel generates a unique token per session and stores it server-side. Every state-changing request (POST, PUT, PATCH, DELETE) must include that token, either in the form body as _token or in the X-CSRF-TOKEN HTTP header. If it's missing or doesn't match, Laravel's VerifyCsrfToken middleware throws a TokenMismatchException, which renders as a 419 response.
That's the whole story. 419 always means CSRF. Now let's fix it.
The Most Common Causes of HTTP 419 in Laravel
Before reaching for a fix, narrow down which scenario you're actually in. The cause determines the right solution.
Missing @csrf in a Blade form. This is the most common one. You built an HTML form, forgot to add the Blade directive, and now every submission fails. Easy to miss, easy to fix.
Session expired. By default, Laravel sessions last 120 minutes (set in config/session.php via the lifetime key). A user opens a tab, gets distracted for two hours, comes back, submits the form. The token is gone. The session is gone. 419.
AJAX request missing the token header. You're using fetch, Axios, or jQuery's $.ajax but haven't configured it to send the X-CSRF-TOKEN header. The form works, but the JS call doesn't.
Mismatched session driver or misconfigured .env. If your SESSION_DRIVER is set to file but the storage directory isn't writable, sessions don't persist between requests. Every request looks like it has no session, so no token ever matches.
Load balancer or reverse proxy dropping session cookies. On staging or production environments behind a proxy, if SESSION_DOMAIN or SESSION_SECURE_COOKIE is misconfigured, the browser won't send the session cookie back, and the server-side token never matches.
Fix 1: Add @csrf to Your Blade Form
If you're working in a Blade template, this is almost certainly the issue. Add the directive right after the opening form tag:
<form method="POST" action="/your-route">
@csrf
<input type="text" name="name" />
<button type="submit">Submit</button>
</form>@csrf compiles to a hidden input field containing the current session's token:
<input type="hidden" name="_token" value="abc123tokenhere">Laravel's middleware reads this field on every POST request and validates it against the session. No directive, no valid token, instant 419.
Fix 2: Configure Axios for AJAX Requests
If you're making JavaScript requests, you need to attach the token to every outgoing request. The cleanest way is to configure Axios globally in your app.js or bootstrap file:
import axios from 'axios';
// Laravel sets this meta tag automatically in your layout
const token = document.querySelector('meta[name="csrf-token"]').getAttribute('content');
axios.defaults.headers.common['X-CSRF-TOKEN'] = token;And make sure your Blade layout actually has that meta tag in the <head>:
<meta name="csrf-token" content="{{ csrf_token() }}">If you're using Laravel's default Vite/Mix scaffold, this is already wired up in resources/js/bootstrap.js. The issue usually appears when someone starts a fresh JS file and bypasses that bootstrap entirely.
For the native fetch API, pass it manually:
fetch('/your-endpoint', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-CSRF-TOKEN': document.querySelector('meta[name="csrf-token"]').content,
},
body: JSON.stringify({ name: 'example' }),
});Fix 3: Extend or Adjust the Session Lifetime
If your users regularly hit 419 after leaving a tab open, the session is expiring on them. Open config/session.php and increase the lifetime:
'lifetime' => env('SESSION_LIFETIME', 480), // 8 hours instead of 2Or set it in your .env:
SESSION_LIFETIME=480This is a reasonable trade-off for internal tools or apps where users work in long sessions. For public-facing apps where security is tighter, consider showing a "Your session has expired, please refresh" message instead of a raw 419. You can do this by catching the TokenMismatchException in your app/Exceptions/Handler.php:
use Illuminate\Session\TokenMismatchException;
public function register(): void
{
$this->renderable(function (TokenMismatchException $e, $request) {
return redirect()->back()
->withInput()
->with('error', 'Your session expired. Please try again.');
});
}That gives users a much friendlier experience than a blank "419 | Page Expired" page. For a deeper look at handling this gracefully, the Coders Vibe article on how to handle 419 page expired in Laravel walks through additional patterns worth knowing.
Fix 4: Exclude Specific Routes from CSRF Verification
Sometimes you genuinely need to skip CSRF. The most common case is a webhook endpoint: Stripe, GitHub, or any third-party service POSTing to your app won't have your session token. Requiring it would break every webhook.
In Laravel 10 and earlier, you'd add the route to the $except array in app/Http/Middleware/VerifyCsrfToken.php:
protected $except = [
'stripe/webhook',
'github/webhook',
'api/*', // excludes all /api routes
];In Laravel 11, with the new slimmed-down application structure, you register the exception inside bootstrap/app.php:
->withMiddleware(function (Middleware $middleware) {
$middleware->validateCsrfTokens(except: [
'stripe/webhook',
'api/*',
]);
})A word of caution here: don't exclude routes casually. CSRF protection exists for a reason. If you're building an API that uses token-based auth (like Laravel Passport or Sanctum), those routes are already protected differently and should be excluded. But don't exclude your regular form routes just to make the error go away. That trades a bug for a security hole.
If you're building a full REST API, the article on authenticating REST APIs with Laravel Passport explains how Passport handles auth without CSRF, which is the correct approach for stateless APIs.
Fix 5: Check Your Session and Storage Configuration
If the fixes above didn't help and you're seeing 419 on literally every request, even fresh ones, the session probably isn't persisting at all. Run through this checklist:
- Is
storage/framework/sessionswritable? Runchmod -R 775 storageand make sure the web server user owns it. - Is
SESSION_DRIVER=filein your.envand is thestoragepath accessible? - If using
SESSION_DRIVER=cookie, isAPP_KEYset? Sessions encrypted with a cookie driver need a valid app key. - If behind a proxy or load balancer, does
config/trustedproxies.php(or the newer middleware config in Laravel 11) correctly list your proxy IPs? - Is
SESSION_DOMAINset to the right domain? A mismatch here means the browser sends the cookie to the wrong host.
After any config change, run php artisan config:clear and php artisan cache:clear. Cached config will override your .env changes otherwise.
Fix 6: SPA or Decoupled Frontend (Sanctum's Cookie-Based Auth)
If you're building a Vue, React, or Next.js frontend that talks to a Laravel API, you're probably using Laravel Sanctum's SPA authentication. This still uses CSRF protection, but through a different mechanism.
Before making any authenticated request, your frontend must call:
GET /sanctum/csrf-cookieThis sets a XSRF-TOKEN cookie. Axios automatically reads that cookie and sends it back as the X-XSRF-TOKEN header on subsequent requests. If you skip this step, every POST gets a 419.
// Call this once at app boot or before any auth flow
await axios.get('/sanctum/csrf-cookie');
// Now your login/register/data requests will work
await axios.post('/login', { email, password });Also confirm that SESSION_DOMAIN in your .env matches the domain of your frontend. For local dev with localhost, set it to localhost. For production, something like .yourdomain.com (with the leading dot to cover subdomains).
Debugging 419 Fast: A Practical Checklist
When you hit a 419 and you're not sure where to start, run through these five questions in order. The answer to the first "yes" is your fix.
- Is the request from a Blade form? Check for
@csrf. - Is the request from JavaScript? Check for the
X-CSRF-TOKENheader. - Is the request from a webhook or external service? Exclude the route from CSRF.
- Did the user wait a long time before submitting? The session expired. Handle
TokenMismatchExceptiongracefully. - Does every single request fail, even fresh ones? The session driver is broken. Check file permissions and config.
Five questions. Most 419s are solved by question one or two. The rest are environment issues that take a bit more digging but follow the same logic.
One More Thing: Don't Disable CSRF Globally
Every few months, someone posts on a forum suggesting you comment out VerifyCsrfToken in your middleware stack to "fix" 419. Don't. That removes CSRF protection from your entire application. You'll stop seeing 419 errors, but you'll also be wide open to cross-site request forgery attacks on every authenticated action your app performs.
The right approach is always to understand why the token isn't arriving and fix that specific gap. The five fixes above cover every legitimate scenario. If none of them apply, something unusual is going on with your infrastructure and that's worth investigating properly, not papering over with a global disable.
If you're running Laravel on shared hosting and hitting environment-related 419 issues, the guide on deploying Laravel on shared hosting covers the permission and config gotchas that often cause session problems in those environments. And if you need to understand more about your Laravel database and config setup, the walkthrough on connecting multiple databases in Laravel is a good reference for understanding how config files and environment variables interact.
The next time a 419 appears, you know exactly what question to ask: where's the token, and why didn't it arrive?
