HTTP 425 Too Early

The server will not process a request sent in TLS early data (0-RTT), because it could be replayed by an attacker.

Defined in RFC 8470 §5.2 — 425 Too Early · MDN reference

Where you meet HTTP 425 in production

CDNs and servers that support TLS 1.3 0-RTT but refuse non-idempotent requests in early data — a replayed POST could charge a card twice.

Why you would test it

Only reachable with TLS 1.3 early data enabled. The test is that the client retries after the full handshake, which most do automatically.

What your client should do about a 425

Retry the same request after the TLS handshake completes, outside early data. Browsers and well-behaved clients do this transparently; a custom client has to do it itself.

425 versus the codes it gets confused with

• 425 vs 429 Too Many Requests — Neither is about the request being wrong, but 429 is rate limiting; 425 is about replay risk in 0-RTT data.
• 425 vs 400 Bad Request — A server without 425 support might return 400 for the same situation.

Endpoints that return 425

1 endpoint in this playground answers with 425. Every one is free, needs no signup, and can be called from the browser or with curl.

• GET https://funapi.dev/api/faults/v1/status/{code} — Returned on request (Fault Injection API) Open & run this endpoint

Questions about HTTP 425

What is TLS early data?

A TLS 1.3 feature letting a returning client send its first request before the handshake finishes, saving a round trip — at the cost of possible replay.

Do I need to handle 425 myself?

Rarely. Clients that send early data are required to retry after a 425.

Other client error codes

• 400 Bad Request
• 401 Unauthorized
• 402 Payment Required
• 403 Forbidden
• 404 Not Found
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required

All HTTP status codes · All 39 mock REST APIs · Getting started guide

Last updated 2 October 2026