Defaults.Exposed

Defaults.Exposed › Reports

HTTP vs HTTPS

Published

HTTP and HTTPS are the same web protocol with one difference that changes everything: HTTPS wraps the connection in TLS encryption, and HTTP does not. Over plain HTTP, every password, form field, and page a visitor loads travels across the network in readable text that anyone in the path can see and alter. The most dangerous version of this is not the site that has no encryption at all — it is the site that has HTTPS but still answers on HTTP and never sends the visitor to the secure version. The August 2026 defaults.exposed census scanned 432,127,908 domains and found 27 million doing exactly that: responding on HTTP and never redirecting, so anything a visitor types on the insecure page is exposed even though a padlocked version exists one letter away. A further 44 million serve no TLS at all. This guide explains what actually differs between HTTP and HTTPS, whether HTTP is ever safe to use, and how to check your own site for free.

If your site loads with a padlock in the address bar, it is easy to assume the HTTP question is settled. It usually is not. A site can hold a valid certificate and still leave its front door open on port 80, quietly serving an unencrypted copy to anyone who arrives without the s. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

HTTP vs HTTPS in one sentence

HTTP (Hypertext Transfer Protocol) is the language browsers and web servers use to request and deliver pages. HTTPS is the same language spoken inside an encrypted TLS tunnel — the S stands for Secure, and the security comes entirely from the TLS layer underneath, not from HTTP itself.

Put plainly: HTTP and HTTPS carry identical content; only HTTPS hides that content from everyone except the two endpoints. An HTTP request for a login page and an HTTPS request for the same page ask for the same thing. The difference is that the HTTP version is a postcard — legible to every network device it passes — and the HTTPS version is a sealed envelope.

For the full mechanics of how that sealed envelope is negotiated — certificates, the TLS handshake, and the chain of trust — see What Is HTTPS: How the Secure Web Actually Works. This article stays on the practical question that brings most people here: what you lose by staying on HTTP, and whether that ever matters for your site.

What actually changes: encryption, integrity, authentication

TLS — the layer that turns HTTP into HTTPS — provides three guarantees at once. Losing HTTPS means losing all three, not just the first.

Encryption — nobody in the middle can read it. Over HTTPS, the request and response are ciphertext to every router, Wi-Fi access point, ISP, and network tap between the visitor and your server. Over HTTP, all of it is plain text: the URL path, cookies, the contents of every form field, the session token that keeps someone logged in. Anyone positioned on the network reads it as easily as you read this sentence.

Integrity — nobody in the middle can change it. TLS detects tampering. Over HTTP there is no such check, so an intermediary can rewrite the page in flight: inject a script, swap a bank-account number on an invoice, replace a download link with malware, or add advertising the site owner never sold. The visitor sees a page that looks like yours and has no way to know it was altered.

Authentication — you are talking to the real server. The TLS certificate proves the server you connected to genuinely controls the domain. Plain HTTP proves nothing about who is answering, which is what makes it trivial for an attacker to impersonate an HTTP site on a shared network. How defaults.exposed grades whether a domain answers on HTTPS at all is documented in the HTTPS-available methodology.

The order matters. People think of HTTPS as “encryption,” but the integrity and authentication guarantees are what stop the most damaging network attacks — the ones that change what a visitor sees rather than merely reading it.

Is HTTP safe? What an attacker on the network can see

Short answer: HTTP is not safe for anything a visitor types, and it is not safe for anything you would not print on a postcard. Whether that matters depends entirely on where the traffic travels and what it contains — but the honest default is to treat plain HTTP as readable by strangers.

To see an HTTP page’s traffic, an attacker does not need to break any encryption, because there is none to break. They need to sit somewhere in the network path. That is not exotic:

On any of those, an HTTP page hands the observer everything: the exact pages viewed, the search terms entered, the login credentials submitted, and the session cookie that can be replayed to hijack an already-authenticated account. None of it requires cracking anything.

And because HTTP has no integrity check, a network attacker is not limited to watching. They can actively modify responses — the class of attack that makes plain HTTP genuinely dangerous rather than merely leaky. This is why “we don’t collect passwords, so HTTP is fine” is a misread: even a brochure site on HTTP can be turned into a malware-delivery page for the visitor sitting on a hostile network, with the real owner none the wiser.

Can HTTP be hacked? The framing is slightly off — HTTP does not get “hacked” so much as read and rewritten, because it offers no protection to defeat in the first place. The attack is passive interception or active man-in-the-middle modification, and both are well within reach of anyone on the same network segment. That is the precise gap HTTPS closes.

The ‘Not Secure’ label and what it costs a business

Since 2018, major browsers mark every plain-HTTP page “Not Secure” in the address bar, and they escalate the warning the moment a visitor focuses a form field. For a business, this is where the abstract security argument becomes a concrete revenue argument.

A visitor who reaches a checkout, a contact form, or a login screen and sees “Not Secure” — or, worse, a full-page interstitial warning them to go back — does not read your TLS configuration. They leave. The cost of HTTP is not a hypothetical breach; it is measurable, daily abandonment at exactly the moments a site is trying to convert.

The reputational edge cuts deeper for small and mid-sized businesses, where a single “Not Secure” warning can undo the trust a customer extended by clicking through in the first place. Search engines compound it: HTTPS has been a ranking signal for years, so an HTTP site is quietly penalised in the results before a visitor ever sees the label.

The reassuring part is that this is one of the cheapest defects on the modern web to fix. TLS certificates are free and automatically renewable from public certificate authorities, and every mainstream hosting platform can provision one in minutes. There is no longer a budget reason to serve “Not Secure” — only an unattended-configuration reason, which is precisely what a scan surfaces.

How common is plain HTTP in 2026? (census data)

You would expect unencrypted HTTP to be a rounding error by now. It is not. Across the 432,127,908 domains the August 2026 census scanned, plain HTTP remains a mainstream failure — and it takes two distinct shapes.

44 million domains serve plain HTTP with no TLS at all. These have no working certificate and no encrypted option to offer; every visitor is unencrypted by necessity. The full breakdown of this population is in the twin report, The HTTP-Only Problem: 44 Million Domains Serving Unencrypted Web in 2026.

27 million domains answer on HTTP and never redirect to HTTPS. This is the more insidious number, and it is this article’s headline finding. These domains often do hold a valid certificate — a secure version of the site exists — but the server still responds on plain HTTP and does nothing to move the visitor across. Anyone who types the address without https://, follows an old HTTP link, or clicks a cached result lands on the unencrypted copy and stays there. Form data and logins submitted on that page travel in the clear despite a padlocked version sitting one redirect away. We measured this cohort in detail in The Last Mile of HTTPS.

The two failures are different problems with the same symptom for a visitor. The first is no lock exists. The second is the lock exists but the door was left open beside it — and the second is worse in one specific way: the owner usually believes they are fully on HTTPS, because when they visit, they type or bookmark the secure URL and never see the gap.

The scale here is not a fringe of abandoned sites. Even setting aside domains that are parked or dead, tens of millions of live, certificate-holding sites are one server-configuration line away from closing the gap and have not. Unencrypted HTTP in 2026 is a default that was never changed, not an edge case.

Redirects and HSTS: HTTPS that can’t be downgraded

Having a certificate is necessary but not sufficient. Two more pieces turn “HTTPS is available” into “HTTPS is unavoidable,” and both are where the 27-million cohort falls down.

The HTTP-to-HTTPS redirect. The server should answer every plain-HTTP request with a 301 (permanent) redirect to the https:// version, so a visitor who arrives on port 80 is moved to the encrypted site before sending anything sensitive. A site with a valid certificate but no redirect is the exact failure behind the 27-million figure: the secure site is there, but nothing forces anyone onto it. How defaults.exposed grades this is documented in the HTTP-to-HTTPS redirect methodology.

But a redirect alone still leaves one gap. The first request — before the redirect arrives — still goes out over plain HTTP, and a network attacker can intercept that first hop and prevent the upgrade from ever happening (an “SSL-stripping” downgrade). That is the gap the next piece closes.

HSTS — HTTP Strict Transport Security (RFC 6797). HSTS is a response header (Strict-Transport-Security) that tells the browser: for the next N seconds, never contact this site over HTTP again — go straight to HTTPS even if the user types http://. Once a browser has seen the header, the vulnerable first request disappears; the browser upgrades the connection itself before anything leaves the device.

HSTS is where most of the web stops. Of the HTTPS-capable population, only 20.1% — 46,539,716 domains — send an HSTS header; the rest can be silently downgraded on that first request. We cover the adoption gap in HSTS Adoption 2026: The Half-Locked Door, the header itself in What Is HSTS, and the grading in the HSTS-header methodology.

The full ladder for a site that wants HTTPS to actually mean something is therefore three rungs, not one:

  1. Hold a valid certificate so an HTTPS version exists at all — see the certificate-validity methodology.
  2. Redirect all HTTP to HTTPS so no visitor is left on the unencrypted copy.
  3. Send HSTS so even the first request cannot be downgraded.

Most sites that people think of as “secure” have completed rung one and stopped. The census numbers are simply what that stopping looks like at internet scale.

What this means

For business owners, the HTTP-versus-HTTPS question is not academic — it is a conversion and trust question with a free fix. A “Not Secure” label at your checkout or contact form costs you customers who never tell you why they left, and a missing redirect means some fraction of your visitors are on the unencrypted copy of your site right now, regardless of what you see when you type your own URL. The certificate is free; the redirect and HSTS are configuration, not cost. The only real expense is not knowing which rung you are on.

For IT and web teams, “we’re on HTTPS” is a claim to verify, not a status to assume. The meaningful checks are three: does a valid certificate exist, does plain HTTP 301 to HTTPS, and is an HSTS header present. A site can pass the first and fail the other two while everyone on the team — who always types the secure URL — believes it is fully protected. The 27 million no-redirect domains are overwhelmingly this: not neglected sites, but sites where nobody checked the plain-HTTP path because nobody uses it internally.

FAQ

Is HTTP safe to use? For anything a visitor types or logs into, no. Plain HTTP sends every form field, password, cookie, and page request across the network in readable text, so anyone on the same Wi-Fi or in the network path can capture it — and because HTTP has no integrity check, they can also alter the page in transit to inject scripts or swap content. Even a site that “collects nothing” is unsafe on HTTP, because a hostile network can rewrite it into a malware page. The August 2026 census found 44 million domains still serving plain HTTP with no encryption at all. If you run a site, check your domain free at defaults.exposed to see whether yours is one of them.

What is the difference between HTTP and HTTPS? They are the same protocol for requesting and delivering web pages; HTTPS runs that protocol inside a TLS-encrypted tunnel and HTTP does not. HTTPS adds three things HTTP lacks: encryption (nobody in the network path can read the traffic), integrity (nobody can alter it undetected), and authentication (a certificate proves you reached the real server). Over HTTP all three are absent — the connection is a legible, modifiable postcard. The content carried is identical; only HTTPS conceals and protects it. The S is provided entirely by the TLS layer, which is why an expired or misconfigured certificate can break HTTPS even when the site “has” it.

Does HTTPS mean a website is safe? No — HTTPS means the connection is private and untampered, not that the site is trustworthy. A phishing page can hold a perfectly valid certificate and show a padlock; the padlock proves you are talking securely to that server, not that the server is honest. HTTPS also does not vouch for the site’s content, its data handling, or its email security. It closes the network-eavesdropping and tampering gap and nothing more. Conversely, a site can have HTTPS available yet still answer on HTTP without redirecting — the census found 27 million domains in exactly that state — so “has a certificate” and “is actually served securely” are two different questions.

Can HTTP be hacked? HTTP is not so much “hacked” as read and rewritten, because it offers no protection to defeat. A network attacker — someone on the same public Wi-Fi, a compromised router, or a malicious hotspot — can passively capture everything an HTTP page sends and receives without breaking any encryption, since there is none. They can also actively modify responses in flight: injecting scripts, altering displayed bank details, or replacing downloads, all invisible to the visitor. This man-in-the-middle capability is the real danger of HTTP, and it is precisely what HTTPS’s encryption and integrity guarantees remove. A missing HTTP-to-HTTPS redirect or absent HSTS header leaves the door open even when a certificate exists.

Data to cite

See where your own domain stands

The HTTP-versus-HTTPS question has a precise answer for your site, and it is not the one you see when you type your own secure URL. The real questions are whether a valid certificate exists, whether plain HTTP is redirected to HTTPS, and whether an HSTS header stops the connection being downgraded — and for tens of millions of domains that look fine to their owners, at least one of those is a no.

Check your domain free at defaults.exposed — it connects to your site over both HTTP and HTTPS, checks your certificate, and tells you instantly whether plain HTTP redirects, whether HSTS is set, and whether a visitor can be left on the unencrypted copy. Takes 30 seconds. No account needed. If you want the whole ladder closed properly — certificate, redirect, and HSTS done right — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Related from this series: The HTTP-Only Problem: 44 Million Domains Serving Unencrypted Web · The Last Mile of HTTPS: 27 Million Domains That Never Redirect · HSTS Adoption 2026: The Half-Locked Door · What Is HTTPS: How the Secure Web Actually Works

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned; HTTP/HTTPS and TLS figures are counts of scanned domains. References: RFC 9110/9112 (HTTP), RFC 8446 (TLS 1.3), RFC 6797 (HSTS).

How to cite this report

Press / blog: defaults.exposed (2026). HTTP vs HTTPS: What’s the Difference and Is HTTP Safe? defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/http-vs-https

Academic: defaults.exposed. (2026, August 21). HTTP vs HTTPS: What’s the Difference and Is HTTP Safe? In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/http-vs-https

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908 domains scanned)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →