What does HTTPS stand for, and what does the S mean?

HTTPS stands for HyperText Transfer Protocol Secure. The S means HTTP is sent over a TLS connection that encrypts the data, protects it from tampering in transit, and authenticates the server with a Certificate. RFC 9110 defines the https scheme this way and sets TCP Port 443 as its default port.

Which is more secure, HTTP or HTTPS?

HTTPS is more secure because it encrypts traffic with TLS, while HTTP sends everything as readable plain text. Anyone on the same network path may see the URL, Cookies and passwords typed into forms, and can alter content undetected. Any site with a login or personal data should use HTTPS and redirect http:// to https:// with a 301 Status Code.

What is the difference between SSL and TLS?

TLS is the successor to SSL and does the same job, but SSL is retired. SSL 3.0 was replaced by TLS 1.0 in 1999, and RFC 7568 (2015) forbids SSLv3. RFC 8996 (2021) then deprecated TLS 1.0 and 1.1. Websites today use TLS 1.2 and TLS 1.3, so "SSL certificate" is just a legacy name for a certificate used with TLS.

Is HTTPS safe on public Wi-Fi?

Yes, for the content: TLS encrypts your passwords, Cookies and the paths of pages you open, so others on the same Wi-Fi cannot read them. They may still see the IP address and the domain name you connect to, via SNI and DNS. If the browser shows a Certificate warning while you are on public Wi-Fi, do not click through and enter data.

What port does HTTPS use?

HTTPS uses TCP Port 443 by default, as RFC 9110 specifies, while plain HTTP uses Port 80. If a URL does not name a port, the browser connects to 443 automatically. You can check a site with openssl s_client -connect example.com:443, which shows the server's Certificate and the TLS version it negotiates.

What does an invalid SSL certificate warning mean?

It means the browser could not validate that site's Certificate. The main causes are an expired certificate, a name on the certificate that does not match the domain, or a certificate not issued by a CA your device trusts, such as a self-signed one. You can check expiry dates with openssl x509 -noout -dates, and you should not enter passwords on a page showing this warning.

What is HTTPS? SSL vs TLS Explained with a Real Certificate

Picture yourself in a cafe, on the free Wi-Fi, logging in to a site with your email and password. At the next table someone has a laptop open on the same network. If that site uses plain HTTP, what you submit travels across the network readable as plain text, and anyone who knows how to watch the network could see your password in full. If the site uses HTTPS, all they get is which site you are talking to. Everything inside is encrypted into something they cannot read.

In short: HTTPS is HTTP sent over a TLS connection, which encrypts the data, stops it being altered in transit, and proves that the server you reach really belongs to that domain. SSL is the name of TLS's predecessor, which has been retired.

Today Superdev Academy walks through how HTTPS works, what actually separates SSL from TLS, and how to inspect a real website's certificate with commands you can type on your own machine.

What is HTTPS, and what does it stand for?

HTTPS stands for HyperText Transfer Protocol Secure, as MDN defines it. The added S is for Secure. The HTTP part is the same protocol your browser already uses to ask a server for a page (a Request) and get one back (a Response).

A common assumption is that HTTPS is a separate protocol. It is not. The current HTTP standard, RFC 9110 section 4.2.2, defines the "https" scheme as HTTP over a TLS connection that has been "secured": the server is authenticated, and the traffic has both confidentiality and integrity protection. GET requests, Status Codes like 200 and 404, and every Header look exactly the same. They are simply sealed inside an envelope that TLS closes for you.

RFC 9110 also fixes the Port. When a URL does not name one, HTTPS defaults to TCP Port 443, while plain HTTP uses Port 80.

HTTP vs HTTPS: what is the difference?

Back to the cafe table. The most concrete difference is what someone sitting in the middle of the connection can see.

HTTP: readable as plain text. That covers the full URL, Cookies and form fields, passwords included. Someone in the middle can also change the content before passing it on, and neither side will know.
HTTPS: encrypted with TLS. Someone in the middle still sees which IP you connect to, and in many cases the domain name, but not the page path, your Cookies or what you typed. If anyone tampers with the data on the way, the other end detects it.

Why does the domain name still leak? Partly because, before encryption starts, the browser has to tell the server which site it wants. That piece of information is called SNI (Server Name Indication). The other part is the DNS lookup that turns a name into an IP, which we cover in What is DNS and how does it work. None of this makes HTTPS pointless. It just means HTTPS protects the content, not the fact of where you went.

What is TLS, and what does it give a connection?

TLS stands for Transport Layer Security, a protocol that sits one layer below HTTP. The TLS 1.3 standard (RFC 8446, August 2018) says it is designed to prevent eavesdropping, tampering and message forgery, and breaks that into three properties.

Confidentiality: once the connection is set up, the data is visible only to the two endpoints.
Integrity: if anyone changes the data in transit, the other end detects it.
Authentication: the server side is always authenticated; the client side optionally.

The third property is where the Certificate comes in. RFC 9110 explains that a browser treats a server as the right one only when the server proves it holds the Private Key matching a Certificate the browser trusts for that domain. Think of a Certificate as the site's ID card, signed by a trusted third party called a Certificate Authority (CA). Your machine already ships with a list of CAs it trusts.

Without that third property, encryption is close to meaningless. Someone in the middle could pose as the server and encrypt everything with you perfectly, and your data would still land in their hands.

SSL vs TLS: what is the difference?

The direct answer: TLS is the successor to SSL (Secure Sockets Layer). Both do the same job, but SSL has been retired completely. The timeline, from the IETF's own documents:

SSL 3.0: replaced by TLS 1.0 back in 1999. RFC 7568 (June 2015) states plainly that SSLv3 MUST NOT be used.
TLS 1.0 and 1.1: RFC 8996 (March 2021) deprecates both with the same wording.
TLS 1.2 and 1.3: the two versions still in use, with TLS 1.3 the latest, defined in RFC 8446.

So why does everyone still say "SSL certificate"?

The name stuck from the era when SSL was the main standard, and plenty of tools still print the word SSL. Even curl, which we use in the next section, reports "SSL connection using TLSv1.3" while the protocol actually running is TLS 1.3. A certificate sold or issued as an "SSL certificate" is the same certificate TLS uses. Whenever you see "SSL certificate", read it as "TLS certificate".

Inspect a real certificate yourself

Rather than asking you to take our word for it, we inspected the certificate for www.superdevacademy.com with OpenSSL 3.6.3 on macOS on 1 October 2026. This command connects to Port 443 and prints just the key fields of the certificate.

$ openssl s_client -connect www.superdevacademy.com:443 -servername www.superdevacademy.com </dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN=www.superdevacademy.com
issuer=C=US, O=Google Trust Services, CN=WE1
notBefore=Aug 21 08:04:58 2026 GMT
notAfter=Nov 19 09:04:55 2026 GMT

Line by line:

subject: the certificate was issued for www.superdevacademy.com, the domain we connected to.
issuer: the CA that signed it is Google Trust Services.
notBefore / notAfter: valid from 21 August to 19 November 2026, a lifetime of 90 days.

The -servername flag sends the domain name (SNI) to the server up front, which is exactly why someone in the middle can still see the domain.

To watch the connection being set up, run curl in verbose mode. Below is curl 8.4.0 on the same day, trimmed to the relevant lines.

$ curl -vI https://www.superdevacademy.com/
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
*  subject: CN=www.superdevacademy.com
*  subjectAltName: host "www.superdevacademy.com" matched cert's "www.superdevacademy.com"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
< HTTP/2 200

The matched cert's line means curl confirmed the name on the certificate matches the domain. SSL certificate verify ok means it confirmed the signing CA is on the list the machine trusts. If either check fails, a browser shows a warning page instead of opening the site.

The padlock does not mean a site is trustworthy

This is the most expensive misunderstanding in the whole topic. The padlock, or https:// in the address bar, tells you two things only: the connection is encrypted, and the server holds a valid certificate for the domain shown in the address bar. It says nothing about whether the owner of that domain is honest.

Scam sites can get certificates like anyone else. Let's Encrypt describes its own process: before issuing, the requester must prove control of the domain, either by publishing a DNS record or by placing a file at a set path on the site. What gets checked is "do you control this domain", not "is this a legitimate business". If the address bar reads paypa1-secure-login.example with a perfect padlock, encryption simply makes sure your password reaches the scammer safely.

So the defence is not looking for the padlock. It is reading the domain name letter by letter before you type a password, and opening important sites from a bookmark or by typing the address yourself rather than tapping a link in a message. If you build websites, HTTPS is only the first layer of security. What comes next in your code is in Secure Coding techniques every beginner should know.

Where do certificates come from, and do they cost money?

They do not have to. Let's Encrypt is a nonprofit CA run by the Internet Security Research Group (ISRG), and its FAQ states that it does not charge a fee for its certificates. Its default certificates are valid for 90 days, and subscribers can opt in to short-lived certificates valid for just 6 days.

Short lifetimes are not unique to Let's Encrypt. The superdevacademy.com certificate we just inspected also runs 90 days. And the CA/Browser Forum, where CAs and browser makers set the rules, adopted Ballot SC-081v3 in 2025 to cut the maximum TLS certificate lifetime in stages, starting March 2026 from 398 days and reaching 47 days in March 2029.

In practice, renewing by hand makes less and less sense; renewal should be automated. For a production setup with Certbot and cert-manager, see EP.125 TLS / WSS and Certificate Management for WebSocket.

Finishing the move to HTTPS: redirects and mixed content

Redirecting HTTP to HTTPS

Having a certificate is not the end of it. When someone types http://, the site should send them to https:// automatically. Here is our own site checked on the same day, trimmed to the relevant lines.

$ curl -sI http://www.superdevacademy.com/
HTTP/1.1 301 Moved Permanently
Location: https://www.superdevacademy.com/

301 Moved Permanently is the Status Code telling the browser the page has moved for good, and Location says the new home is https://. For the other codes, see HTTP Status Codes List Explained.

What is mixed content?

According to MDN, mixed content is a page loaded over HTTPS that fetches some of its resources over HTTP, such as an image or script linked with http://. Those resources can be read or modified in transit, so the page is not as safe as the padlock suggests. MDN splits it into two groups.

Upgradable: images, audio and video. The browser rewrites the request to HTTPS itself and logs a warning in the Console.
Blockable: scripts, stylesheets, iframes, fetch() requests and web fonts. The browser blocks them outright.

A common symptom after moving a site to HTTPS is a broken layout or buttons that do nothing. The cause is usually a CSS or JavaScript file still linked with http://. To track it down, open the DevTools Console, see which files were blocked, and change each link to https:// one at a time.

Summary: what is HTTPS, and why does it matter for using websites?

HTTPS is HTTP running over TLS, not a new protocol. It matters because of the three things TLS provides: data such as passwords and Cookies cannot be read in transit even on public Wi-Fi, content cannot be altered without detection, and you really are talking to that domain's server. SSL is the retired older name that survives only in the phrase "SSL certificate". And the padlock only tells you the connection is secure, not that the site's owner deserves your trust.

Open a Terminal and run the openssl command above against a site you use every day. See who the issuer is, when the certificate expires, and whether that site's http:// redirects to https://. Five minutes looking at the real thing turns this from vocabulary into something you understand.

Follow more articles and tips for people starting out as programmers on our channels.

Facebook: Superdev Academy Thailand (https://www.facebook.com/superdev.academy.th)

YouTube: Superdev Academy Channel (https://www.youtube.com/@SuperdevAcademy)

Instagram: @superdevacademy (https://www.instagram.com/superdevacademy/)

TikTok: @superdevacademy (https://www.tiktok.com/@superdevacademy?lang=th-TH)