← All guides
Guide

What "TLS 1.3 only" costs you in browser and client compatibility

Published May 27, 2026. About a five-minute read.

Disabling TLS 1.2 and going TLS 1.3 only is a popular item on hardening checklists. The pitch is simple: TLS 1.3 removed every cryptographic primitive that has ever been broken, mandates forward secrecy, and cuts the handshake to one round trip. Why keep the older version?

The honest answer is that TLS 1.2 is still the floor for a non-trivial slice of clients in 2026, and “TLS 1.3 only” quietly excludes them. Here is what that actually looks like in practice, and how to think about whether the trade is worth it for your site.

What you gain from TLS 1.3 only

  • No way for a client to negotiate a CBC cipher, RC4, 3DES, or any of the historical bad picks. The TLS 1.3 cipher list contains only AEAD ciphers.
  • Forward secrecy is mandatory. No more RSA-key-exchange suites that fail to forward-secret.
  • Faster handshakes (one round trip instead of two, and zero round trips for resumed sessions).
  • A smaller protocol surface to audit. TLS 1.3 cut a lot of negotiation that historically had to be locked down by hand in TLS 1.2 configs.
  • A configuration that ages well. There is no realistic future-day where you wish you had kept TLS 1.2 enabled.

Who you lock out

The list is small and shrinking, but it is not empty. As of 2026:

  • Pre-2018 desktop browsers. Chrome and Firefox added TLS 1.3 in 2018. Anything earlier is gone. On modern user populations this is a rounding error, but the count is non-zero on sites that serve schools, public libraries, and emerging-market regions where device refresh cycles are longer.
  • Safari before macOS 10.13 / iOS 11. Released in 2017. On current Apple hardware this is gone. On a fleet of older iPads and Macs that still run, it can still matter.
  • Older Android. Android 10 (2019) and later support TLS 1.3 cleanly. Android 4 and 5 do not. Android 7-9 support depends on the system Conscrypt version, which not every device updates.
  • Server-to-server HTTP clients in older language runtimes. Python 3.6 on a long-running CentOS 7 box, .NET Framework 4.6 without explicit configuration, Java 8 before update 261 (without enabling TLS 1.3 via system properties). These show up more often than you expect in B2B integrations, partner webhook receivers, and legacy enterprise stacks.
  • IoT and embedded devices. Anything using an mbedTLS or wolfSSL build older than 2019. Set-top boxes, smart TVs, point-of-sale terminals, industrial sensors. Every one of those is a customer somewhere.

How to decide

The honest framing is: who are your visitors?

  • Consumer web app with a young, mobile-heavy audience. Going TLS 1.3 only is fine. You will lose almost nobody.
  • Public-sector or accessibility-focused site. Keep TLS 1.2 with a tight cipher list. The fraction of users on older devices is meaningfully larger and they tend to be the people who most need the service.
  • API consumed by partners or enterprise integrations. Keep TLS 1.2. The cost of one big customer's integration breaking on a Sunday morning is higher than the cryptographic upside of removing it.
  • Internal dashboards. Go TLS 1.3 only. You know your client population.
  • E-commerce or anything that touches payment data. Keep TLS 1.2 with the modern subset of cipher suites. PCI DSS allows TLS 1.2 and the visitor cost of dropping it is a real revenue cost.

The middle path

For most sites the right answer is not “TLS 1.3 only”. It is “TLS 1.2 and 1.3, with TLS 1.2 restricted to AEAD ciphers and ECDHE key exchange.” You get almost all of the security benefit of TLS 1.3 (because the only TLS 1.2 suites you offer are the modern ones) while keeping the long tail of older clients working.

A reasonable nginx config:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

This is the Mozilla “intermediate” profile in two lines. It is the right default for the public internet in 2026.

How to know what you would lose

If you have web analytics, check the rough share of visitors on browsers older than 2018 and on Android below 10. Cross- reference with your server access logs by user-agent. The absolute number is usually small, but it is rarely zero. That is the visitor cost of “TLS 1.3 only.”

Disable TLS 1.2 only after that number drops to where the cryptographic benefit clearly outweighs the lost reach for your audience. There is no universal right answer; there is your answer for your visitors.