Check whether TLS 1.3 is negotiated for 0-RTT early data
Results
About 0-RTT Checker
0-RTT early data lets a returning client send application data immediately after its ClientHello, without waiting for the handshake to finish. This page confirms the one thing an external probe can establish: whether TLS 1.3 is actually negotiated. Whether the server accepts early data cannot be determined from a single handshake, because proving it requires sending early data on a resumed connection — so this page does not claim it, and tells you how to test it yourself instead.
Use Cases
•Verify TLS 1.3 early data support on your web server
•Understand where 0-RTT fits and what it actually removes from the handshake
•See how anti-replay protection is actually verified
•Optimize TLS handshake performance for returning users
How to Use
•Enter the domain name you want to test for 0-RTT support
•Click "Check" to perform the early data test
•Review the negotiated TLS version and what it does and does not prove about early data
Frequently Asked Questions
0-RTT (Zero Round-Trip Time) is a TLS 1.3 feature that allows clients to send data to the server immediately after the ClientHello, without waiting for the handshake to complete. This reduces connection latency for returning visitors who have previously established a session.
0-RTT can be vulnerable to replay attacks if not properly protected. The TLS 1.3 specification requires servers to implement anti-replay mechanisms. Anti-replay protection is a server-side configuration choice that no external checker can verify from outside, because it lives in how the server treats tickets it has already seen. This page deliberately does not claim to inspect it. Verify it the way that actually proves it: enable 0-RTT on a test endpoint, capture an early-data request, and replay it to confirm the server rejects the second copy.
0-RTT can reduce connection latency by one full round trip compared to a full TLS 1.3 handshake. For geographically distributed users, this can mean 50-200ms reduction in time-to-first-byte, significantly improving perceived performance for returning visitors.
No, and the page is explicit about that rather than guessing. It confirms TLS 1.3 is negotiated, which is the necessary precondition. Whether the server accepts early data requires sending early data on a resumed connection, which this probe cannot perform. An earlier version of this page reported 0-RTT as supported whenever 1.3 negotiated, which claimed a feature it never tested — a version check is not a feature test.
With openssl s_client and the -early_data flag, twice against the same server so the second connection can attempt resumption, and look for the early-data acceptance in the output. Note that many servers cap how long a ticket is usable for early data, and CDNs often terminate the session in front of the origin, so the answer you get may describe the edge rather than your server.
No. It is a server-side decision about how the server treats tickets it has already seen, and nothing in a handshake reveals it. This page previously claimed to verify it, which it never could. The verification that actually proves it is behavioural: enable 0-RTT on a test endpoint, capture an early-data request, replay it, and confirm the server rejects the duplicate.
One round trip, on resumed connections only. A first visit pays the full handshake regardless, and early data arrives before the server has authenticated the client — which is precisely why replay protection matters. For most sites the effect is modest and concentrated in returning visitors, so it ranks well below session resumption, which delivers the same round-trip saving without the replay risk.
Marginally at best, and usually not measurably. Resumption already removes the handshake cost for returning clients, so 0-RTT's marginal gain is small and applies only to a fraction of connections. If you are chasing performance metrics, HTTP/2 or HTTP/3 support, connection reuse and server response time move the numbers far more than 0-RTT does.
What Is Measured Here
0-RTT early data is only available over TLS 1.3. This page confirms the version a connection actually negotiates — the prerequisite — and is explicit about the part it cannot establish.
1Complete a handshake and read the negotiated version. TLS 1.3 is the gate: without it, early data is impossible on this connection no matter what the server is configured to allow.
2Report that version plainly. A server negotiating 1.3 has cleared the only precondition checkable from a single connection, and that is exactly what the result states.
3Say plainly what remains untested. Whether the server accepts early data is not reported, because proving it requires sending early data on a resumed connection — something this probe cannot do. An earlier version of this page reported 0-RTT as supported whenever 1.3 negotiated, and its FAQ claimed anti-replay verification that never existed.
To confirm 0-RTT for real, use openssl s_client with -early_data against the server twice and watch for an early-data indication, then verify anti-replay by replaying the captured request and confirming the second is rejected.
Tips & Best Practices
•Enable 0-RTT early data for faster TLS handshakes on repeat connections
•Understand the security implications of replay attacks with early data
•Configure replay protection for applications accepting early data
•Monitor early data usage for performance optimization
Technical Details
Measured: the TLS version negotiated with this connection Reported: whether that version is TLS 1.3, the prerequisite for 0-RTT Not measured: whether early data is accepted, and anti-replay configuration — both require a resumed connection carrying early data Output: the negotiated version with an explicit note on what remains untested
