What you'll learn
Quick Answer
HTTPS is HTTP inside a TLS-encrypted connection. It provides confidentiality, integrity and server authentication. It does not verify that the site is trustworthy, and it does not hide which server you connected to.
HTTPS is HTTP in an encrypted tunnel
The protocol is unchanged. The same requests, methods, headers and status codes — carried inside a TLS connection instead of in the open.
Over plain HTTP, everything is readable by anything on the path: the café Wi-Fi, the ISP, every intermediate router. Not only passwords — the exact pages, form contents, cookies and session tokens.
TLS provides three things:
- Confidentiality — observers cannot read the contents.
- Integrity — contents cannot be modified in transit undetected.
- Authentication — the server proves it holds the private key for a certificate issued to that domain.
Integrity is underrated. Over plain HTTP, an intermediary can inject content into a page. ISPs have historically inserted advertisements into unencrypted pages, and HTTPS makes that impossible rather than merely detectable.
How the authentication works
The server presents a certificate: the domain it covers, a public key, and a signature from a certificate authority the browser trusts.
The browser checks it was signed by a trusted authority, that it covers the domain being visited, and that it has not expired. If any check fails you get the full-page warning — and that warning genuinely matters, because it is exactly what an interception attack looks like.
Certificates are free now, which removed the last reason to stay on HTTP. Let's Encrypt issues them automatically, and most hosting includes it with a checkbox.
What the certificate proves is narrow but important: you are talking to the holder of the key for this domain, and nobody in between can read it. That is all.
What the padlock does not mean
This is the part people get wrong, and phishing depends on it.
The padlock does not mean the site is honest. Anyone can obtain a certificate for a domain they control, including priodemy-verify-account.com. A phishing site will show a padlock, because the connection to the criminal really is encrypted.
The advice "look for the padlock" is therefore outdated. The useful check is the domain name — read it carefully, right to left, and confirm it is the organisation you expect.
Nor does HTTPS hide everything. An observer can still see which server you connected to, roughly how much data moved, and when. The page contents are protected; the fact of the connection is not.
It also protects only data in transit. Once at the server, security depends entirely on that operator — HTTPS says nothing about whether they store your password properly.
Mixed content, and why the padlock disappears
A page served over HTTPS that loads a script, stylesheet or image over HTTP is mixed content.
It undermines the whole page: an attacker who can modify that HTTP script can do anything on your HTTPS page, because the script runs with full access. Browsers therefore block mixed scripts and stylesheets outright and warn about images.
The symptom is a page that works locally and breaks after deployment with console errors about blocked content. The fix is to load every resource over HTTPS — use protocol-relative or absolute https:// URLs, and check any embedded third-party widget.
Related: once on HTTPS, redirect HTTP to it and enable HSTS, which instructs browsers to use HTTPS for your domain in future and removes the brief unencrypted first request.
Why it matters for your projects
Beyond security, HTTPS is now a practical requirement:
- Browser APIs require it. Geolocation, camera, microphone, service workers and notifications refuse to run on HTTP, so a progressive web app simply will not work.
- Browsers mark HTTP as "Not secure" in the address bar, which visitors notice.
- It is a search ranking signal, minor but free.
- HTTP/2 and HTTP/3 are effectively HTTPS-only in browsers, so plain HTTP is also slower.
For a student project this costs nothing — every major free host provides HTTPS automatically. See deploying your project for free, and TCP/IP explained for where TLS sits in the stack.