The HTTPS Story: From Chrome 68 in 2018 to 99% of Web Traffic in 2026

How HTTPS became the web standard: from Chrome 68 to 2026

When you visit any website in 2026, the Chrome address bar shows either a lock icon or nothing at all — HTTPS is now taken for granted, not celebrated as an achievement. On the flip side, if a site still runs on plain HTTP, the browser throws up a full-screen red warning: "Attackers may be trying to steal your information." The conversion rate of such pages is zero.

Eight years have passed since Chrome 68 first rolled out the "Not Secure" label next to HTTP site addresses in July 2018. It wasn't the loudest event in web history, but it forced millions of site owners to migrate to HTTPS in a matter of months — something they had been postponing for years.

This article is about how we got here, what has changed over eight years, and where the web is heading in the near future. The technical details (how to configure TLS on Nginx, which certificate to choose, how to migrate without losing SEO) are covered in separate articles — we'll link to them where relevant.

Life before HTTPS: a brief backstory

HTTPS didn't appear in 2018 alongside Chrome 68. The SSL protocol was born back in 1995 at Netscape — literally at the dawn of the commercial web. But until the 2010s, it was used mainly by banks, payment gateways, and login pages on large services. The rest of the internet ran on plain HTTP.

This wasn't a problem as long as two conditions held: traffic flowed through trusted ISPs, and users weren't sitting in public networks. Both assumptions collided with reality in the early 2010s:

• Public Wi-Fi became available everywhere. Coffee shops, hotels, airports, subway. On an open wireless network, any neighbor with a sniffer could read all HTTP traffic around them — passwords, cookies, private messages.
• ISPs started injecting ads. First selectively, then en masse. If a site ran over HTTP, the provider could legally (and often illegally) inject its own banner straight into the page body during transmission.
• Traffic sniffing went industrial-scale. After 2013, when the Snowden documents were published, it became clear that mass traffic interception is not theory but actual state-level practice.

Decrypting each HTTPS request cost resources and time, but by 2014 that was no longer a serious barrier. The web was ready for the transition — it just needed a push.

2014: Google makes HTTPS a ranking factor

In August 2014, Google officially announced that HTTPS would be a signal in search ranking algorithms. At that point the weight of this signal was minimal — the company explicitly said: "affects fewer than 1% of queries and carries less weight than content quality." But the direction was set: secure sites would gain an edge, and insecure ones would gradually lose positions.

Many people ignored the signal. At the time, switching to HTTPS looked like a tough task: you had to buy a certificate ($50–500 per year from commercial CAs), configure the server correctly, fix mixed content, rewrite all internal links, and set up 301 redirects from HTTP. For most small and medium businesses, it meant money and hours of work with no obvious return.

That's when Google pulled the levers that eventually flipped the situation.

2015: Let's Encrypt launches

In April 2015, Let's Encrypt launched — a non-profit certificate authority issuing SSL certificates for free. Backed by Mozilla, EFF, Cisco, Akamai, and other industry players. This eliminated the financial barrier entirely: a certificate now cost zero dollars and auto-renewed every 90 days.

By the end of 2016, Let's Encrypt had issued 24 million certificates. By 2020 — a billion. It became the de facto standard for most sites in the world.

2017: warnings on password forms

In January 2017, Chrome 56 started showing the "Not Secure" label on HTTP pages that contained password or credit card fields. It wasn't full HTTP labeling yet, but the visible signal was clear: Google was preparing the transition.

Site owners got eighteen months of warning. Those who heard it migrated. Those who didn't got a surprise in July 2018.

July 2018: Chrome 68 and the end of the HTTP era

On July 24, 2018, Chrome 68 was released. In the changelog — a line that changed the web: every site without HTTPS now received the "Not Secure" label in the address bar, regardless of whether the page had forms or not.

At that point, Chrome controlled more than 60% of the global browser market. That meant 6 out of 10 visitors to your site saw the warning the moment they arrived. Conversion rates of HTTP e-commerce stores dropped 2–3x on the very first day after the browser update.

What happened next

Within months of Chrome 68's release, the HTTPS share of internet traffic rose from ~70% to ~85%. By the end of 2019, to 95%. It was the fastest mass migration to a new security standard in web history.

Chrome publishes these numbers in its open Transparency Report — they can be verified anytime. The dynamics are clear: in eight years HTTPS went from "nice to have" to "without it, the site doesn't exist."

What HTTPS actually does

Encryption is often understood narrowly — "the data can't be read." In reality, HTTPS solves three separate tasks, known in cryptography as the CIA triad (Confidentiality, Integrity, Authenticity).

Confidentiality

Traffic between the browser and the server is encrypted with modern algorithms (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305). If someone intercepts the packets, they see a meaningless stream of bytes. Brute-forcing the key would take longer than the lifetime of the solar system.

Integrity

Every transmitted block is signed with a cryptographic MAC (Message Authentication Code). If someone tries to modify a packet in transit — even a single bit — the receiver sees that the signature doesn't match and tears down the session. That means: an ISP can no longer slip an ad banner into your page, and an attacker on public Wi-Fi can't inject JavaScript malware into the response.

Authenticity

A certificate issued by a trusted CA proves that the domain belongs to the organization that operates it. This blocks phishing copies of your site under the same domain — the browser simply won't trust a forged certificate. Man-in-the-middle (MITM) attacks, where an attacker impersonates the real server, are impossible without a compromised CA.

What HTTPS does NOT do

This is important to understand, because "I have SSL, so I'm safe" is a common mistake. HTTPS protects only the transport channel. Everything else is a separate problem:

What changed in HTTPS in the eight years after Chrome 68

The 2018 article described the situation as it stood back then. In eight years, web encryption technology has changed substantially — and in many cases for the better without any action required from the site owner, at the browser and server level.

TLS 1.3 became the default

TLS 1.3 was released in August 2018 as RFC 8446 — practically at the same time as Chrome 68. The initial handshake shrank from 2 RTT to 1 RTT, support for 0-RTT for repeated connections (session resumption) was added, and legacy ciphers (RC4, 3DES, SHA-1) were cut from the protocol entirely.

By 2026, TLS 1.3 is the default in Nginx, Apache, IIS, and Caddy out of the box. TLS 1.2 is still supported for compatibility, but TLS 1.0 and 1.1 are officially deprecated by the IETF (RFC 8996) and blocked by browsers.

Mixed content is fully blocked

Previously, if an HTTPS page loaded an image or script over HTTP, the browser showed a broken padlock but let the content through. In 2020, Chrome started blocking mixed content by default: first scripts and styles, then images, then everything. In 2026, mixed content simply doesn't load — no exceptions.

HTTP/3 went to production

HTTP/3 on top of QUIC (UDP instead of TCP) is supported in 2026 by Cloudflare, Google, Facebook, most major CDNs, and modern versions of Nginx. It technically requires HTTPS — without encryption, QUIC simply doesn't exist. In other words, the HTTPS transition opened the door to the next generation of transport protocols. Details are in our article on HTTP/3 and its impact on performance.

Certificates got short-lived

In 2020, the maximum validity of public certificates was capped at 398 days (previously 3 years). In 2024, the CA/Browser Forum voted for further reductions — down to 47 days by 2029. The logic is simple: shorter validity means faster revocation of compromised certificates. In practice this means: without automation (Certbot, acme.sh), maintaining certificates by hand is no longer feasible.

HSTS and preload lists became the norm

The HSTS (HTTP Strict Transport Security) header, mentioned in the 2018 article as a "bonus," is in 2026 a standard part of any baseline configuration. Major sites (Google, Facebook, banks) are included in the preload list, which is hardcoded into browsers. That means the browser won't even try HTTP on the first visit.

On the horizon — post-quantum cryptography

In 2024, Chrome began experimenting with post-quantum key exchange algorithms (X25519Kyber768). The logic: when (or if) sufficiently powerful quantum computers appear, they will be able to break current public-key cryptography. So engineers at major companies are already preparing standards that will be resistant. In 2026 this is still an experiment, but in 3–5 years it will become the new norm — like TLS 1.3 in its time.

If your site is still on HTTP

In 2026 this is a rare case, but such sites still exist — usually old corporate pages that haven't been updated in years, or internal systems no one got around to. If that's you, the migration was due yesterday.

A short plan without the details:

1. Get a certificate. For most sites — free Let's Encrypt via Certbot. For e-commerce with a financial guarantee — commercial OV/EV from DigiCert or Sectigo.
2. Configure the server. Nginx or Apache with TLS 1.2/1.3 support, modern ciphers, OCSP stapling. Verification — SSL Labs, A grade or higher.
3. Fix mixed content. All internal links, image paths, CSS, JS — switch to HTTPS. Verification — DevTools in Chrome, the Console tab will show all blocked resources.
4. Set up 301 redirects from HTTP to HTTPS. For search engines and users coming via old links. Without redirects, SEO rankings are lost.
5. Update Google Search Console. Add the HTTPS version as a separate property, refresh sitemap.xml, verify indexing.
6. Enable HSTS. The header that forces the browser to use only HTTPS. After verifying everything works — apply for the preload list.

What HTTPS will look like in the coming years

If the trend of the last eight years continues, the next five will bring several important changes.

47-day certificates

The CA/Browser Forum approved a phased reduction of the maximum certificate validity: 200 days (2026) → 100 days (2027) → 47 days (2029). This will definitively kill the market for manual certificate management — without automation, no site will survive. The good news: Certbot and acme.sh have worked this way for years, so there's nothing special to learn.

Post-quantum cryptography

Between 2025 and 2027, browsers and servers will gradually gain support for hybrid key-exchange algorithms (classical + post-quantum). By 2030 this will be the standard. The site owner won't need to do anything special — an Nginx or Apache update will bring the new algorithms automatically.

ECH (Encrypted Client Hello)

A TLS extension that encrypts even the domain name during the handshake. Currently the hostname is visible in plain text — even if the rest of the traffic is encrypted, the ISP can see which sites you visit. ECH closes this gap. Cloudflare already supports it; Chrome is rolling it out in stages. Broad support is expected by 2027.

DoH/DoT becoming the default

Encrypted DNS queries (DNS over HTTPS, DNS over TLS) are already enabled in Chrome and Firefox, but only conditionally. In a few years this will become the default behavior — and the last major "hole" in what your provider can see about your activity will close. Details are in our article "What is DNS and how it works."

Frequently asked questions