HTTP and HTTPS: what changes when a site is secure

Updated: Oct 28, 2026

Every web page, image, form submission and API call travels over HTTP, the Hypertext Transfer Protocol. HTTPS is the same protocol carried inside an encrypted, authenticated tunnel. The difference looks like one letter and a padlock icon, but it decides whether anyone between you and the server, a café Wi-Fi operator, an internet provider, a compromised router, can read what you send, alter what you receive, or pretend to be the site you think you are visiting. This article explains what HTTP actually does, what the S adds, and what the padlock does and does not promise.

What TLS adds to an HTTP request

HTTP is a request-response protocol. The client, usually a browser, opens a connection and sends a request consisting of a method, a path, headers and optionally a body:

GET /articles/http-and-https/ HTTP/1.1
Host: example.com
Accept: text/html
Cookie: session=abc123

The server replies with a status code, headers and a body:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600

<!doctype html> ...

Methods express intent: GET reads, POST submits, PUT replaces, DELETE removes. Status codes report outcome in families: 2xx success, 3xx redirection, 4xx client error (404 not found, 403 forbidden, 401 unauthorised), 5xx server error. Headers carry everything else: content type, caching rules, cookies, compression, language preferences. Newer versions of the protocol, HTTP/2 and HTTP/3, keep the same semantics but multiplex many requests over one connection and, in HTTP/3, run over UDP to avoid head-of-line blocking; the request and response you see in developer tools look the same.

What the S adds

Plain HTTP is text on the wire. Anyone on the path can read every request and response, including cookies and form fields, and can change them: inject advertisements, swap a download for malware, or redirect a login form. HTTPS wraps the connection in TLS (Transport Layer Security), which provides three guarantees:

• Confidentiality. The content is encrypted; observers see only which server you connected to and roughly how much data moved.
• Integrity. Any modification in transit is detected and the connection fails rather than delivering altered data.
• Authentication. The server presents a certificate, signed by a certificate authority the browser trusts, proving it controls the domain in the address bar. An impostor cannot obtain a valid certificate for someone else’s domain.

The handshake at the start of the connection negotiates keys using public-key cryptography, then switches to fast symmetric encryption for the data. Modern TLS 1.3 completes this in one round trip, so the performance cost is small and, with HTTP/2 available only over HTTPS in browsers, encrypted sites are often faster than plain ones.

What the padlock means, and what it does not

The padlock means the connection to the domain shown is encrypted and the certificate is valid. It does not mean the site is honest, safe or the one you intended. A phishing site at paypa1-secure.com can have a perfectly valid certificate and a padlock; certificates are free and automated. Read the domain name, not the icon. Conversely, a “Not secure” warning on a static informational page means the content could be tampered with in transit, which matters less for a recipe than for a login form, but browsers now treat all plain HTTP as a problem, and search engines and advertising networks expect HTTPS everywhere.

Mixed content

An HTTPS page that loads a script, stylesheet or image over plain HTTP undermines its own protection: an attacker who alters that script controls the page. Browsers block insecure scripts and styles outright and upgrade or block insecure images. Site owners behind a TLS-terminating proxy commonly hit this when the application believes it is serving HTTP and generates http:// asset URLs; the fix is to tell the application it is behind HTTPS or to use protocol-relative or absolute HTTPS URLs.

Checking that a connection is really secure

• Read the domain in the address bar before entering credentials; the padlock alone proves nothing about who owns the site.
• Never submit passwords or card details on a page marked “Not secure”.
• If you run a site, serve everything over HTTPS, redirect HTTP to HTTPS, and send the Strict-Transport-Security header so browsers refuse plain connections in future.
• Use automated certificates (Let’s Encrypt or your host’s equivalent) so they never expire unnoticed.
• Check for mixed content in the browser console after any change to the site’s structure.
• Learn the common status codes; a 404 versus a 500 versus a 403 points at completely different causes.

Frequently asked questions

Can my internet provider see which sites I visit over HTTPS?

They see the domain name through DNS and the TLS handshake (unless encrypted DNS and Encrypted Client Hello are in use), but not the pages, queries or content.

Why does a site show a certificate error?

The certificate expired, was issued for a different name, is self-signed, or the chain to a trusted authority is broken. Occasionally your device’s clock is wrong. Do not click through on sites where you will enter anything sensitive.

Is HTTPS slower?

Marginally, for the handshake; in practice HTTPS enables HTTP/2 and HTTP/3, which more than compensate. There is no longer a performance argument for plain HTTP.

HTTP carries the web; TLS makes sure nobody rewrites it on the way.

In short: HTTP is a request-response protocol of methods, paths, headers and status codes. HTTPS runs it inside TLS, giving confidentiality, integrity and proof that you are talking to the domain shown. The padlock certifies the connection, not the site’s intentions, so read the domain, and serve everything over HTTPS if you publish.