419 Page Expired 4xx

What does 419 mean?

419 Page Expired is a non-standard status code — it doesn't appear in the official IANA HTTP status code registry — used by some web frameworks specifically to indicate that a form submission failed because a CSRF (Cross-Site Request Forgery) token was missing, invalid, or expired. Rather than returning a generic 403 or 401 for this specific situation, some frameworks use 419 as a more descriptive, framework-specific signal.

CSRF protection works by embedding a unique token in forms when a page is rendered; when the form is submitted, the server checks that the submitted token matches what it expects. If a session has expired, or the token is otherwise stale/invalid, the submission is rejected — and 419 is one way some frameworks communicate "this specific kind of rejection" distinctly from other 4xx errors.

How a 419 behaves

• It's not part of the official HTTP specification — it's a convention adopted by specific frameworks/applications, not something all servers or clients universally recognize
• It typically results from a form submission (POST), not from normal page navigation (GET) — CSRF protection applies to state-changing requests
• The underlying cause is almost always a session/token mismatch — either the session expired between when the form was loaded and when it was submitted, or the token itself wasn't included/transmitted correctly

Common causes

If you're building the website:

• A user loaded a form, left the tab open for longer than the session lifetime, then submitted it — by the time of submission, their session (and the CSRF token tied to it) has expired
• A user has multiple tabs open, and session/token state from one tab conflicts with another
• A caching layer is serving a stale page containing an old CSRF token to users, while the server-side session has since changed

If you're calling an API:

• 419 is primarily a browser form submission concept tied to CSRF protection — typical JSON APIs (which usually rely on token-based auth like Bearer tokens, not CSRF tokens) wouldn't normally produce this; if you're seeing it from an API, it likely indicates the request is hitting a web (non-API) route that has CSRF protection enabled

If you're a website visitor:

• You left a form open for a long time (went to lunch, got distracted) and then submitted it — your session expired in the meantime
• You're using browser back/forward navigation to return to a previously-submitted or cached form page and resubmitting it

How to fix it

As a website builder:

• Display a clear, user-friendly message when 419 occurs — "Your session expired, please try again" is far more helpful to users than a raw error
• Consider whether session/token lifetimes are appropriately long for your use case — very short session lifetimes increase how often legitimate users encounter this
• For long forms, consider periodically refreshing the CSRF token client-side (via a background request) so long-open forms don't expire unnecessarily
• Ensure caching configurations don't serve pages containing CSRF tokens in a way that creates token/session mismatches for different users or sessions

As an API consumer:

• If you're getting 419 from what you expected to be an API endpoint, check whether you're actually hitting a web/CSRF-protected route instead of the intended API route — these often have different base paths or require different authentication mechanisms entirely

As a website visitor:

• Refresh the page and resubmit the form — this generates a fresh session/token
• Avoid leaving forms open for extended periods before submitting, especially on sites with shorter session timeouts
• If using multiple tabs of the same site, be aware that session state in one tab could affect form submissions in another

419 vs 401 vs 403

Real-world examples

This status code is most commonly associated with certain PHP web frameworks that use it as a default response for CSRF token validation failures on form submissions — when a session expires and a previously-loaded form is then submitted, the framework's CSRF middleware detects the mismatch and returns 419 with a corresponding error page, rather than a generic 403.

SEO implications

419 is specific to form submissions (POST requests with CSRF protection), not page navigation (GET requests) that search engines crawl — it has no direct relevance to indexable content.

FAQ

Is 419 an official HTTP status code?

No — it's not part of the IANA-registered status code list. It's a convention used by certain web frameworks specifically for CSRF token/session expiration on form submissions.

What is CSRF protection, briefly?

A security mechanism that embeds a unique, session-tied token in forms; when the form is submitted, the server verifies the token matches what's expected for that session — preventing malicious sites from tricking a user's browser into submitting unauthorized requests using their existing session.

Why would a framework invent its own status code instead of using 403?

To provide a more specific, debuggable signal distinguishing "this is specifically a CSRF/session-expiration issue" from other kinds of "forbidden" responses (like genuine permission denials) — though since 419 isn't standardized, not all clients/tools recognize it specially, and ultimately it's still a 4xx-range client error.

How long do CSRF tokens/sessions typically last before causing 419?

This varies by framework/application configuration — commonly ranging from a couple of hours to a full day of inactivity, though specific values depend on session configuration settings.

Can 419 happen even with correct login credentials?

Yes — 419 relates to the CSRF token/session state at the time of this specific form submission, independent of whether your login credentials are generally valid. A long-idle session can expire (triggering 419 on the next form submission) even if your account credentials themselves remain entirely valid.

Fun fact

419 occupies an interesting niche as a status code that's simultaneously "non-standard" and yet extremely commonly encountered by anyone who's used certain types of web applications for long enough to have a session expire mid-form — illustrating how individual frameworks sometimes fill genuine gaps in the official specification with their own conventions, which then become a kind of de facto standard within their own ecosystems even without formal IANA registration.