Look at your browser’s address bar right now. The site almost certainly starts with “https” and shows a small padlock, and if it did not, your browser would probably warn you before letting you continue. That one extra letter, the “s,” quietly reshaped the web. That little “s” stands for secure, and it is way more important than people give it credit for. This blog is a plain spoken comparison of HTTP and HTTPS: what actually differs between them, why it matters, and where the real nuance lives.
HTTP vs HTTPS at a glance
Here is the short answer before the detail. HTTP and HTTPS are the same protocol. Same methods, same headers, same status codes, same URL structure. An HTTPS request is byte-for-byte the HTTP request it would have been; it just travels differently. HTTPS is HTTP carried inside a TLS session, which is why the definition is so thin: a scheme, a default port, and an instruction to complete the TLS handshake before speaking HTTP. What TLS adds is three properties, not only encryption.
Confidentiality: data travels encrypted. Anyone on the path sees ciphertext which is indistinguishable from noise, rather than your request in readable text.
Integrity: TLS uses authenticated encryption, which means that any modification on a record fails authentication and the connection tears down, rather than quietly delivering altered content.
Authentication: the server presents a digital certificate binding its public key to the name of the server that you typed, chaining to a trust anchor your browser already held.
That last one is arguably the most important part. Without it, an attacker in the path simply establishes an encrypted connection with you and separate one with the origin, and confidentiality buys nothing.
Port 80 vs port 443
A port is a number that indicates which program on a machine the network traffic is meant for. When network traffic shows up on your computer’s door, it looks at the port that it carries and announces that to the computer, which then routes it to the right program. Web browsers use port 80 to connect to web servers via the HyperText Transfer Protocol (HTTP). HTTPS uses port 443, where the connection is encrypted and the server is authenticated. When a browser needs a secure connection, it automatically switches to the encrypted path, as long as the server has a valid certificate installed.
Plain text vs encrypted
HTTP is a plain text protocol outlying everything on the wire: headers, cookies, body, etc., which means it is relatively easy for someone to intercept and read the data in transit and learn everything that was sent during the communication. It is not adequate for anything that requires confidentiality. Moreover, HTTP exposes users to unauthenticated servers which may carry malware or other present other threats. HTTPS instead encrypts the communication and authenticates the server. Even if an attacker captures the traffic, the encrypted content appears as unintelligible gibberish unless they hold the correct decryption key.
How you can tell
The easiest way to check is to look at the URL. A secure site starts with “https” and shows a padlock icon near the address bar. Click that padlock and you can view the certificate details, including who issued it and when it expires.
In the terminal, you can also monitor everything that is currently open and going through a port. For example, for port 443,
ss -tnp state established ‘( dport = :443 or sport = :443 )’
A short history: how the web went secure by default
HTTP came first, and for years it was the web’s unencrypted default. Security was added on top over time, and the pieces that made HTTPS possible arrived in stages.
The plain text era
In the early web, data traveled in the open. HTTP moved pages and form submissions as readable text, in the sense that anyone with a packet capture could scroll through a session the way you’d scroll through a document. That was a design choice, not an oversight. Tim Berners-Lee’s original protocol had one method and no headers; it fetched hypertext documents from physics servers for an audience of physicists. The early days were governed by the academic tradition of openness, with no fear of bad actors. Encryption would have been overhead in service of a threat that didn’t exist yet.
What broke the assumption wasn’t a flaw in HTTP. It was commerce and the fear of malware. Once the web carried credit card numbers and login credentials, “readable by anyone on the path” stopped being a neutral property. And it was also important to feel safe when visiting a website, knowing that the entity on the other side is exactly who they say they are.
From Netscape SSL to modern TLS
Netscape developed SSL in the 1990s to encrypt and secure internet communications.
- SSL v1.0 was never released because of security issues.
- v2.0 arrived in 1995 with many flaws.
- v3.0 followed in 1996 with major improvements.
- The Internet Engineering Task Force then built TLS as the successor: TLS v1.0 in 1999, v1.2 in 2008, and v1.3 finalized in 2018.
- By 2020, SSL was fully deprecated, and TLS v1.2 and v1.3 became the protocols still in use, even though people still casually say “SSL.”
For the full comparison of SSL and TLS, check out our HTTPS everywhere
Modern browsers now assume security by default. Chrome, Firefox, Edge, and others default to HTTPS and flag non secure pages, which is why an HTTP-only site increasingly triggers a warning rather than a silent load. This default has become “layered” so to speak.
- The first one of these layers is about the behavior of the address bar: for example, typing keyfactor.com resolves to https://www.keyfactor.com.
- The second one is about navigation upgrade: if you click the link http://www.keyfactor.com, or one embedded in a page, it gets silently retried over HTTPS, with a fallback to plaintext if the upgrade fails.
- The third one is HTTPS-First mode: this one drops the fallback and shows a full warning page. The user can still proceed, but they must explicitly indicate to do so.
The threat model: what really happens on plain HTTP
The reason browsers push so hard toward HTTPS is not cosmetic. Plain HTTP exposes real, exploitable weaknesses.
Eavesdropping and interception
On unsecured HTTP connections, anyone positioned on the network path can intercept messages between the browser and server and read them in plain text. Encrypted connections scramble that communication until the intended recipient decrypts it, so an interceptor sees nothing usable, which is especially important if the communication contains personally identifiable information, sensitive data, passwords, etc.
Man in the middle attacks
When you visit a website, your browser sends a request, and the server returns a response. Without protection, that interaction is vulnerable to man-in-the-middle attacks, where a malicious actor intercepts the data in transit and can extract or alter it. For example, if you log in to an online banking portal and someone intercepts that traffic, your credentials could be exposed, potentially leading to identity theft or financial loss.
Trust, phishing, and the need for Public Key Infrastructure
Encryption is only half the story. A valid certificate issued by a trusted Certificate Authority (CA) also authenticates the server, proving the site is who it claims to be. If a website asks for sensitive information and has no certificate, that connection should not be trusted with any private data. Server authentication proves that a certificate belongs to the domain in the address bar, not that the domain is the one the user meant to visit. Phishing exploits that gap, since an attacker who registers a convincing lookalike domain can obtain a valid certificate for it and present a fully authenticated connection to a site the user does not actually trust. HTTPS therefore protects both the confidentiality of the exchange and the identity of the site. To learn more about Certificate Authorities, check out our dedicated guide on CAs, or read our deep dive on PKI to have a wider perspective of the trust infrastructure.
The future threat: harvest now, decrypt later
There is also a forward-looking risk. Current encryption is secure against classical computers, but not against sufficiently powerful quantum computers, which are likely to be realized in the coming 5-15 years. This has raised concern over (HNDL) attacks, in which adversaries record encrypted traffic today and intend to decrypt it later once quantum capabilities mature.
To defend against this, the industry is moving toward post-quantum cryptography, which runs on normal computers, yet will remain resistant to attacks even after powerful quantum computers are built. Part of this cryptographic migration includes replacing traditional key exchange with quantum-resistant mechanisms in future versions of TLS.
What HTTPS still does not hide
Here is the honest part that often gets skipped: HTTPS protects the content of your requests, but it does not make you invisible. Encryption hides what you send and receive so an interceptor sees only gibberish, yet several signals remain in the open.
Metadata that stays visible
The destination IP address is still observable, because the network has to route your traffic somewhere. In many setups, the domain name is also exposed through DNS lookups, and the server name is sent early in the connection. An observer may not read your messages, but can often tell which service you are talking to.
Traffic patterns
The size and timing of your traffic can leak information on their own. Distinct patterns, such as the rhythm of a video stream or the shape of a login sequence, can hint at what is happening even when the payload is encrypted.
What encryption cannot fix
Encryption secures data in transit, not at the ends of the conversation. A compromised device, malware on your computer, or a malicious site that holds a perfectly valid certificate are all outside what HTTPS can address. A padlock confirms the connection is encrypted and the certificate is valid; it does not vouch for the intentions of whoever is on the other end.
When plain HTTP is still acceptable
Plain HTTP is not universally wrong. A few legitimate, low risk cases remain, though the honest recommendation keeps narrowing.
Non sensitive, internal, or isolated contexts
Internal tooling and local development, where no private data changes hands, can run over HTTP without much concern. Traffic to your own machine never touches a network, so there is no interceptor to worry about. This is also why Domain Validated certificates, the most basic and fastest type to issue, are aimed at personal or internal sites rather than public, data-collecting business websites.
There is also a principled corner where HTTP is correct by design. Some signed objects carry their own integrity regardless of how they travel, so serving them over HTTP is intentional rather than a shortcut. And certain bootstrap steps, such as the initial redirect from an “http://” address to “https://,” have to start on port 80 before a secure connection exists.
Why “acceptable” is shrinking
The list of acceptable HTTP cases keeps getting shorter, for good reasons. Browser defaults now mark plain HTTP as “not secure” regardless of content. Certificates have become free and automatically renewing through the ACME protocol, now widely supported by several PKI platforms such as EJBCA, so the old excuse that certificates are expensive or manual no longer holds. As well, “trusted internal network” is a weaker assumption than it used to be, as zero-trust thinking treats no network location as inherently safe. For anything public or handling user data, HTTPS is the standard and expected choice.
How Keyfactor can help
HTTPS only works when the certificates behind it are valid and trusted, and that is exactly where many organizations struggle. The pressure is intensifying: the CA/Browser Forum has voted to shorten certificate lifespans to a 200-day maximum by 2026, 100 days by 2027, and just 47 days by 2029. Miss a renewal and a site can go down, users lose trust, and your security posture takes a hit. Manual tracking does not scale to that pace.
Keyfactor helps teams keep every site on HTTPS without outages. EJBCA provides the platform to create the certificates that TLS depends on, while Bouncy Castle delivers a full TLS stack for developers. On the discovery side, AgileSec finds cryptographic assets and certificates across your environment, so nothing hides in a blind spot. Keyfactor Command manages certificates across the enterprise, tracking expiration dates, and automating provisioning and renewal, so that multiple-certificate sprawl and surprise expirations become a thing of the past. Together they cover certificate lifecycle automation, PKI, and cryptographic discovery, and they help teams prepare for post-quantum readiness as the standards evolve.
Got HTTP vs HTTPS questions? We’ve got answers.
What is the main difference between HTTP and HTTPS?
HTTP sends data in plain text over port 80, so it can be intercepted and read. HTTPS adds encryption over port 443, scrambling the data so only the intended server and browser can read it. HTTPS also authenticates the server’s identity.
Is HTTPS just HTTP with encryption?
HTTPS is HTTP carried over an encrypted, authenticated connection. That layer adds confidentiality, server authentication, and data integrity, none of which plain HTTP provides.
How can I tell if a site uses HTTPS?
Look at the address bar. A secure site’s URL starts with “https” and shows a padlock icon. Clicking the padlock lets you view the site’s certificate details.
Why do browsers warn me about HTTP sites?
Because data on HTTP can be intercepted and read in plain text. Browsers such as Chrome now default to HTTPS and flag non secure pages to protect users from eavesdropping and phishing.
Does HTTPS hide everything I do online?
No. HTTPS encrypts the content of your requests, but details such as the destination IP address, the domain you visit, and traffic size and timing can still be visible. It also cannot protect a device that is already compromised.
Is it ever okay to use plain HTTP?
For isolated internal tools or local development that handle no sensitive data, HTTP can be acceptable. For any public site or one collecting user data, HTTPS is the standard and expected choice.
Does HTTPS help with SEO?
Yes. HTTPS is a positive ranking signal, and a valid certificate improves user trust, both of which support search visibility.
What makes HTTPS trustworthy?
An SSL/TLS certificate issued by a trusted Certificate Authority proves the site’s identity and enables encryption. The browser verifies that certificate through a chain of trust back to a trusted root.
