# HTTPS Explained: What It Protects and What It Does Not

Source: https://urbanx.co.za/knowledge-hub/digital-safety-privacy-account-protection/https-what-it-protects

**Answer:** HTTPS protects data moving between a browser or app and the authenticated website endpoint. It is designed to prevent eavesdropping, undetected alteration and impersonation of another domain during the connection. It does not prove that the organisation behind the displayed domain is honest, that the site is free of malware or that information will be handled safely after it arrives.

Part of [Digital Safety, Privacy & Account Protection](https://urbanx.co.za/knowledge-hub/digital-safety-privacy-account-protection) · 9 min read · by UrbanX Knowledge Hub

**Last reviewed: 26 August 2026 · 9 min read**

### What the “S” adds

Ordinary HTTP describes how web requests and responses are exchanged. HTTPS carries HTTP inside a TLS-protected connection.

TLS 1.3 is designed to provide three central properties:

- **Confidentiality:** protected content is visible to the endpoints, not ordinary network observers.
- **Integrity:** an attacker should not be able to alter protected data without detection.
- **Authentication:** the browser verifies the server’s identity for the domain using certificates and trust infrastructure.

This is why a browser can send a password or payment form without exposing that content as readable text to every network carrying the packets.

### What HTTPS normally protects

After a secure connection is established, protected application data includes:

- the specific page content;
- username and password fields;
- form submissions;
- payment details submitted to the site;
- session cookies;
- the URL path and query string;
- messages or files sent through the service; and
- the site’s response.

The website and its authorised service endpoints still receive the data. HTTPS is encryption in transit, not a promise that the recipient never stores, shares or misuses information.

### What remains outside the promise

HTTPS does not hide all traffic metadata. A network still handles:

- source and destination IP addresses;
- timing;
- packet and connection sizes; and
- transport information needed to deliver the exchange.

Other destination information may be visible depending on DNS, SNI and modern encryption features. [What Can Your ISP See?](/knowledge-hub/digital-safety-privacy-account-protection/what-can-isp-see-internet-activity) explains this carefully.

### A padlock is not a character reference

Browsers can establish HTTPS with a domain controlled by a criminal. The connection may be encrypted perfectly while the domain is a lookalike designed to steal credentials.

For example:

- `urbanx.co.za` and `urbanx-support.example` are different domains;
- a subdomain can place a trusted brand word before the criminal’s actual registered domain;
- substituted characters can be difficult to notice; and
- a QR code can conceal the destination until it opens.

The browser’s security indicator means the connection to the displayed domain is protected. The user must still confirm that it is the intended domain and a legitimate request.

### What certificates do

A website presents a certificate that binds cryptographic keys to a domain identity under a trusted certificate system. The browser validates the certificate, dates, domain match and trust chain as part of the connection.

Most ordinary certificates validate control of a domain, not the honesty, financial health or customer-service quality of the business. A valid certificate should therefore be treated as necessary connection protection, not complete due diligence.

### Browser warnings matter

Stop when a browser reports:

- “Your connection is not private”;
- a certificate-name mismatch;
- an expired or untrusted certificate;
- an unsafe-site or malware warning; or
- an unexpected request to install a certificate or configuration profile.

Do not bypass the warning merely because a message says the payment is urgent. Navigate to the organisation independently or contact it through a known channel.

There are legitimate causes of certificate errors, including incorrect device time or site misconfiguration, but the user should not solve an urgent transaction by disabling protection.

### HTTPS cannot protect a compromised endpoint

Encryption does not help when:

- the device has malware that records input before encryption;
- a malicious browser extension reads page content;
- the genuine website account is already taken over;
- the user sends information to the wrong legitimate account;
- the site itself is breached; or
- a person voluntarily discloses an OTP or recovery code to a scammer.

The connection can be secure while the device, account, recipient or decision is unsafe.

### HTTPS and public Wi-Fi

Widespread HTTPS has greatly reduced the old risk of a nearby hotspot user reading ordinary website content in plain text. It remains important to verify the hotspot name, heed warnings and keep devices updated.

[Staying Safe on Public Wi-Fi](/knowledge-hub/digital-safety-privacy-account-protection/staying-safe-public-wifi) covers the remaining risks without assuming every hotspot is hostile.

### A safer website check

Before submitting sensitive data:

1. Read the full domain from right to left around the registered name.
2. Confirm HTTPS without bypassing warnings.
3. Navigate from a saved bookmark, known app or manually typed address.
4. Check that the action makes sense for the account.
5. Verify unexpected payment or credential requests independently.
6. Use browser unsafe-site warnings as a stop signal.
7. Do not install profiles, certificates or remote-access tools on instruction from an unknown contact.

### Sources

- [RFC 9846: The Transport Layer Security Protocol Version 1.3](https://www.rfc-editor.org/info/rfc9846/)
- [Google Chrome: Check If a Site’s Connection Is Secure](https://support.google.com/chrome/answer/95617)
- [Google Safe Browsing Site Status](https://transparencyreport.google.com/safe-browsing)
- [CISA: Understanding Website Certificates](https://www.cisa.gov/news-events/news/understanding-website-certificates)
- [CISA: Shopping Safely Online](https://www.cisa.gov/news-events/news/shopping-safely-online)

### Related guides

- [All Digital Safety, Privacy & Account Protection guides](/knowledge-hub/digital-safety-privacy-account-protection)
- [What Can Your ISP See About Your Internet Activity?](/knowledge-hub/digital-safety-privacy-account-protection/what-can-isp-see-internet-activity)
- [How to Check Whether a Website or Payment Link Is Legitimate](/knowledge-hub/digital-safety-privacy-account-protection/check-website-payment-link-legitimate)
- [Staying Safe on Public Wi-Fi](/knowledge-hub/digital-safety-privacy-account-protection/staying-safe-public-wifi)

## Frequently Asked Questions

**Does HTTPS mean no one can hack the website?**

No. It protects the connection. The website, account, application and device can have separate vulnerabilities.

**Can a phishing website use HTTPS?**

Yes. Criminals can obtain certificates for domains they control. Check the actual domain and request.

**Does HTTPS hide the page path from the ISP?**

The path and query are inside the protected request. Other connection and destination metadata may remain.

**Is HTTP safe for reading a public page?**

Unencrypted HTTP lacks the confidentiality and integrity protections of HTTPS. An observer may read or alter traffic. Do not submit credentials or sensitive information.

**Should I ignore a certificate warning if I trust the company?**

No. Verify through another channel and let the site owner correct the problem. Trust in a brand does not repair an unsafe connection.
