Defaults.Exposed › Reports

TLS 1.3 Adoption in 2026: 94.8% of TLS-Reachable Domains

Published 2026-08-01 · updated2026-08-13

Figures as of 2026-07-29 · methodology v8. Aggregate census data; we never publish an individual domain’s status or grade. See how we grade.

Roughly nineteen of every twenty domains that can hold a modern encrypted conversation now hold it on TLS 1.3. The upgrade arrived with the software, not the administrator. TLS is the encryption protocol behind HTTPS. A handshake is the short exchange that starts every secure connection. This edition of our census covers the 297 million domains we graded. Of those, 210 million complete a TLS handshake with our scanner. Within that TLS-reachable group, 94.8% negotiate TLS 1.3, the modern standard. The other 5.2% settle for TLS 1.2. Nothing older shows up at all: no current browser offers the deprecated versions by default, and neither does our scanner.

We spend most of this site documenting failure: dead zones, missing email authentication, unsigned DNS. This article is the exception. It shows the internet can fix itself almost completely. It also shows when that happens.

What percentage of websites use TLS 1.3 in 2026?

94.8% of TLS-reachable domains negotiate TLS 1.3 as of 2026-07-29. We measure registered domains, not individual websites. In our June 2026 edition the figure was 90.5%, measured on that edition’s HTTPS-reachable set. The negotiated version is one of the few figures we compare across editions, because it is directly observed and measured the same way each time. Composite grades are different: each edition’s grades are a snapshot of that edition’s own methodology, so they do not travel between editions.

Our scanner connects the way a current browser does. It offers TLS 1.2 and 1.3, the only versions modern browsers still speak. Whatever version the server and scanner then agree on is the “negotiated” version. On those terms, 210,439,319 domains complete the handshake. 199,590,201 land on TLS 1.3 and 10,849,118 stop at TLS 1.2.

One caveat, stated plainly. This table records the version each server negotiated with us. Our client, like every modern browser, will not go below TLS 1.2. Two things follow.

First, a server that negotiates TLS 1.3 with us may still be willing to speak an older protocol to an older client. A single handshake cannot reveal that willingness, and we do not pretend it can. Our weak and outdated TLS guide covers what still-accepted legacy versions and weak ciphers mean for you.

Second, a server that can only speak TLS 1.1 or below never completes our handshake at all. Servers like that are not counted in this table.

What the table does show is the conversation the web actually has with virtually every current browser. It is the best-case handshake, and the one that matters most. One handshake tells you which row your own domain lands in — run the free scan.

What did TLS 1.3 actually fix?

Three things. Each mattered on its own.

It made connection setup faster. TLS 1.3 removes a full network round trip from the standard handshake. Its 0-RTT resumption mode goes further: returning visitors skip the handshake wait entirely. On a mobile connection where every round trip is slow, users can feel the difference. It is a rare case of the secure option also being the fast option.

It made forward secrecy the standard. In the TLS 1.3 full handshake, session keys are ephemeral: used once, then gone. The protocol is designed so that a stolen or subpoenaed server key cannot, on its own, decrypt recordings of past traffic. That protection is called forward secrecy. Resumption modes carry narrower caveats, but the default path is protected. In earlier versions this protection was optional. Now it is simply how the standard handshake works.

It deleted the foot-guns. TLS 1.3 did not just discourage weak options. It removed them. Legacy ciphers, static key exchange, TLS-level compression, insecure renegotiation: that list is the raw material behind a decade of named attacks, including BEAST and POODLE. None of it is merely “disabled by default” in TLS 1.3. It is gone. The protocol no longer defines those options, so within TLS 1.3 itself there is no configuration path back into those vulnerability classes. One reminder from the caveat above: a server that still accepts older protocol versions keeps that older surface alive.

That last point is the theme of this story. TLS 1.3 is safer chiefly because it is smaller: fewer options to handle badly.

Who is still negotiating TLS 1.2 — and does it matter?

So who are the 5.2%? Those 10,849,118 domains tend to cluster in recognisable places: hosting stacks whose HTTPS software predates the modern default, ageing load balancers and security appliances with frozen TLS libraries, and embedded or legacy corporate servers nobody dares touch. That description comes from industry experience, not from the census. The census records the negotiated version, not the software behind it. Still, it fits the shape of the number. For most laggards, the likeliest story is software old enough that the better default never arrived.

Does it matter? Less than the raw split suggests. TLS 1.2 with a modern cipher configuration is still broadly accepted. PCI DSS, the payment-card security standard, currently requires strong cryptography rather than mandating TLS 1.3. Some regimes, though, are beginning to require the newer version. Requirements evolve, so check the current text of any framework that applies to you.

The genuinely striking figure sits below the table. Every major browser disabled TLS 1.0 and 1.1 by default in 2020. Our scanner, like those browsers, does not offer them. So no handshake with a current client can land on a deprecated protocol. Could some servers still quietly accept the old versions from a legacy client? That is the caveat from earlier: a single modern handshake cannot see it.

TLS version is the check your domain almost certainly passes. That also makes it the least informative one. A single free scan reads your TLS version and the checks where most domains fail. DMARC is one: the DNS record that tells receiving mail servers what to do with email that fails authentication. 74.19% of the domains we could evaluate have no DMARC record at all.

Why did TLS 1.3 win while DMARC is stuck at 11.84%?

No two numbers in this census say more about how security actually spreads.

TLS 1.3 did not reach 94.8% because 199,590,201 administrators each read a specification and acted. It spread because a handful of actors changed what happens when nobody chooses anything. Server software projects, content delivery networks (CDNs) and managed hosting platforms flipped the default. Whole fleets of customer domains upgraded because the infrastructure underneath them upgraded.

Now compare the controls that wait for the domain owner to act:

Evaluated = graded domains whose DNS we could query. Dead domains are excluded from per-check denominators. The rows use different denominators, as labelled.

Same internet. Same edition. Same stakes: email spoofing and DNS forgery are not lesser threats than passive eavesdropping.

The percentages sit on different bases, and it is worth saying so. 94.8% is measured on the 210 million domains that complete a TLS handshake. Measure TLS 1.3 on the full 297 million graded domains instead, and it still reaches roughly two in three. DMARC enforcement stands at 11.84% on the slightly smaller base of domains we could evaluate for DMARC. Pick any denominator you like: the gap survives.

The variable is not awareness or importance. It is whether the secure behaviour is the easy path. Where security shipped as the default, adoption came close to total. Where it needs a deliberate act for every domain, it sits at 11.84% and 6.28% of evaluated domains.

That asymmetry is the founding argument of this site. It is in the name.

Two of the three rows in that table are waiting for you. The free scan reads your domain against all three: TLS version, DMARC policy and DNSSEC. It typically takes under a minute. Check your domain.

What this means for your business

Compliance has already moved. Payment-card rules forced early TLS off cardholder systems years ago. Security questionnaires now treat protocol version as a table-stakes check. If your stack negotiates TLS 1.3, you are comfortably ahead of that line on protocol version. If a vendor’s stack still cannot, that is a fair prompt to ask about their patching and upgrade cadence. Every one of those handshakes also rides on a certificate — see who actually issues the web’s certificates for that half of the story.

Being in the 5.2% is now visible. Automated vendor-rating tools, cyber-insurance scans and procurement checklists read your TLS version from the outside, in seconds. When 94.8% of the reachable web negotiates the modern standard, topping out at TLS 1.2 invites follow-up questions. It can also shave points off automated ratings. That is friction you do not want in a deal review. A line item that genuinely fails, such as a deprecated protocol or a weak cipher, can stall procurement for weeks and hand the deal to the vendor who passed. If a modern stack or CDN fronts your site, enabling TLS 1.3 is often a one-line setting. The stacks still stuck on 1.2, though, are frequently the ones where that line is hardest to change. The usual escape hatch is a CDN in front — see how to fix your TLS. Everything those tools read is public. Run the free scan: it reads the same public records the rating tools read, and there is nothing to install.

The lesson generalises: buy defaults, not promises. The clearest pattern in this census is simple. Controls switched on upstream are present at far higher rates than controls left to each domain owner. So when you choose a hosting, email or DNS provider, ask the most valuable question first: what is on by default? Nearly everyone claims to support everything.

And the mirror lesson: your email will not fix itself. No CDN will flip your DMARC policy to enforcement the way the web’s infrastructure flipped on TLS 1.3. That control sits at 11.84% precisely because it waits for you. See where your policy stands with the free scan, then fix your DMARC.

Your domain answers this article in a single handshake. The free scanner at defaults.exposed reads your negotiated TLS version, your DMARC policy, your DNSSEC status and the rest of our checks from the public internet. No signup, no agent, and typically a grade in under a minute. Find out which side you are on.

Quick answers

What percentage of websites use TLS 1.3? 94.8% of the 210 million TLS-reachable domains in the defaults.exposed census negotiate TLS 1.3 as of 2026-07-29. We measure registered domains rather than individual websites. 5.2% negotiate TLS 1.2, and a modern handshake offers nothing older. Live figure: what percent of websites use TLS 1.3.

Is TLS 1.2 still safe in 2026? As of 2026-07-29, TLS 1.2 with a modern cipher configuration is still broadly accepted under major compliance frameworks. Requirements are tightening, though, so verify the regime that applies to you. In our industry experience, the 5.2% of domains that negotiate TLS 1.2 usually reflect older infrastructure rather than a deliberate choice. The census records the negotiated version, not the reason behind it. For still-accepted legacy versions and weak ciphers, see our weak and outdated TLS guide. You can read any domain’s negotiated TLS version, along with its DMARC and DNSSEC status, free at defaults.exposed. No signup.

Why is TLS 1.3 adoption so much higher than DMARC adoption? TLS 1.3 reached 94.8% of TLS-reachable domains because servers, CDNs and hosting platforms turned it on by default. DMARC enforcement sits at 11.84% of evaluated domains because every owner has to act individually. The two figures sit on different bases: TLS 1.3’s is of TLS-reachable domains. Even on the full graded base, though, TLS 1.3 still reaches roughly two in three domains.