425 Too Early 4xx
The server is unwilling to process a request that might be replayed, sent before the connection is fully established.
What does 425 mean?
A 425 Too Early response means the server is unwilling to process a request that was sent as part of a TLS connection's "early data" — a feature introduced in TLS 1.3 that allows clients to send data immediately as part of the initial handshake, before the connection is fully confirmed, as a performance optimization (avoiding a full round-trip before the first real request can be sent).
The catch: early data is vulnerable to replay attacks — because of how the optimization works, an attacker who intercepts this early data could potentially resend it, and the server might process it again. For requests where this would be dangerous (anything with side effects — POST, PUT, DELETE), 425 tells the client "I'm not willing to process this as early data; please resend this after the connection is fully established."
How a 425 behaves
- It's specific to TLS 1.3 early data — this code doesn't apply to connections that don't use this feature at all
- It can carry a body, though it's primarily a signal for the client's HTTP stack to handle automatically rather than something requiring human-readable explanation
- The client should retry the request after the TLS handshake completes — most modern HTTP client implementations handle this transparently, automatically resending the request once the connection is fully established
- It's specifically a safety mechanism for non-idempotent requests — GET requests (which are idempotent and safe to repeat) are generally fine as early data; it's requests with side effects where replay risk matters
Common causes
If you're building/operating infrastructure:
- You're using TLS 1.3 with early data ("0-RTT") enabled, and a client sent a non-idempotent request (POST, PUT, DELETE) as early data — your server is correctly protecting against replay risk by returning 425
If you're calling an API:
- Your HTTP client supports TLS 1.3 early data and sent a request before the handshake fully completed — this is almost always handled automatically by the client library, with 425 triggering an automatic retry rather than surfacing as a visible error
If you're a website visitor:
- Essentially never visible — this operates entirely at the TLS/connection layer, handled transparently by browsers
How to fix it
As an API/website builder:
- If you support TLS 1.3 early data, returning 425 for non-idempotent requests sent as early data is the correct, secure behavior — this isn't something to "fix" so much as a security feature working as intended
- Ensure your server/infrastructure correctly signals 425 (rather than, say, processing a potentially-replayed POST) when early data is used for requests with side effects
As an API consumer:
- This is virtually always handled automatically by HTTP client libraries supporting TLS 1.3 — if you're implementing very low-level TLS/HTTP handling yourself, ensure your client retries appropriately on 425 rather than treating it as a hard failure
- In normal usage with standard libraries, you should never need to handle 425 manually
As a website visitor:
- Not applicable — entirely transparent at the protocol level
425 vs other codes
| 425 Too Early | 429 Too Many Requests | |
|---|---|---|
| What it's protecting against | Replay attacks on TLS 1.3 early data for non-idempotent requests | Excessive request rate from a client |
| Expected client behavior | Retry once the connection is fully established (often automatic) | Wait and retry later, respecting Retry-After |
| Visibility to typical developers | Essentially invisible — handled by TLS/HTTP libraries | Often visible and requires explicit handling |
Real-world examples
TLS 1.3's 0-RTT (zero round-trip time) resumption feature is the entire reason 425 exists — it's a relatively recent (2018) addition to HTTP specifically to address a security implication of a relatively recent (also 2018-era) TLS feature, making it one of the more "modern" status codes in terms of the technology it relates to. CDNs and reverse proxies that terminate TLS connections are typically responsible for implementing 0-RTT support and the corresponding 425 behavior — application-level code rarely interacts with this directly, as it's handled at the TLS termination layer.
SEO implications
None — 425 is a TLS-connection-layer security mechanism entirely unrelated to page content, crawling, or indexing.
FAQ
What is TLS 1.3 "early data" / "0-RTT"?
It's a performance optimization in TLS 1.3 that allows a client reconnecting to a server it has previously connected to, to send application data (like an HTTP request) immediately as part of the initial handshake, rather than waiting for the handshake to fully complete first — saving a round-trip of latency.
Why is early data risky for some requests?
Because of how 0-RTT resumption works, early data could potentially be captured and replayed by an attacker, causing the server to process the same request twice. For a GET request (idempotent, no side effects), processing it twice is harmless. For a POST that, say, charges a credit card, processing it twice would be a serious problem.
Do I need to handle 425 myself in my application code?
Almost certainly not — this is handled at the TLS/HTTP client library level. If your environment supports TLS 1.3 early data, the client library should automatically retry on 425 without your application code needing any special handling.
Is 425 a sign that something is wrong with my connection?
No — it's a normal part of the TLS 1.3 early-data safety mechanism working correctly. It's the expected response for certain requests sent as early data, not an error indicating a problem.
Does every server/connection encounter 425?
Only connections using TLS 1.3 with early data (0-RTT) enabled, and only for non-idempotent requests sent during that early-data window. Many connections never trigger this at all, either because TLS 1.3 early data isn't in use, or because the relevant requests are GET requests where this concern doesn't apply.
Fun fact
425 is one of the newest status codes in this entire reference, standardized in 2018 (RFC 8470) specifically to address a security nuance introduced by another relatively new technology (TLS 1.3's 0-RTT, also standardized around the same time) — a good example of how the HTTP status code registry continues to evolve in direct response to changes happening at other layers of internet infrastructure, even as codes like 200 and 404 remain essentially unchanged since the 1990s.