What is HTTPS (Hypertext Transfer Protocol Secure)?
Updated: 3 days ago
HTTPS (Hypertext Transfer Protocol Secure) is HTTP carried over a Transport Layer Security (TLS) connection. TLS encrypts the HTTP data travelling between your browser or application and the HTTPS server, protects it against undetected alteration in transit, and normally authenticates the server for the hostname you requested. The crucial distinction is that HTTPS protects the connection in transit; it does not prove that the website itself is honest, safe or free from malicious content.
Modern HTTPS is therefore best understood as two layers working together: HTTP defines the web request and response semantics, while TLS supplies the cryptographic protection around that exchange. A padlock or HTTPS address tells you about the protected connection to the server identified by the certificate, not whether you should trust everything the site says or does.
How does HTTPS work?
When you enter an HTTPS URL, the browser first needs to reach the destination server. DNS may be used to resolve the hostname, and the client then establishes the underlying network connection. TLS is negotiated before ordinary protected HTTP application data is exchanged.
The browser resolves the hostname and connects to the server or service endpoint.
The client and server negotiate a supported TLS version and cryptographic parameters.
The server presents a certificate chain containing its public-key information and the names for which the certificate is valid.
The browser validates the certificate chain, hostname, validity period and other applicable checks against its trust store and security policy.
The TLS handshake establishes shared traffic keys.
HTTP requests and responses are then carried inside the protected TLS connection.
The IETF defines HTTP semantics in RFC 9110, while TLS 1.3 is specified separately. Keeping those layers separate matters: HTTPS is not a replacement for HTTP; it is the secure use of HTTP over TLS.
What does HTTPS protect?
Confidentiality: protected application data is encrypted so passive observers on the path cannot simply read the HTTP content.
Integrity: TLS detects unauthorised changes to protected records rather than silently accepting modified data.
Server authentication: the certificate and TLS validation process help the client establish that it is communicating with a server authorised for the requested hostname.
These properties are about data in transit. They are especially important when requests contain passwords, session cookies, personal information, payment data, API credentials or other sensitive material.
What HTTPS does not protect you from
A malicious website that legitimately obtained a certificate for its own domain.
Phishing where the attacker persuades you to visit the wrong but correctly secured hostname.
Malware, browser extensions or compromised software running on your own device.
A compromised web server that can see data after TLS terminates.
Tracking performed by the website itself through accounts, cookies or other application mechanisms.
Every form of traffic metadata. Parties on the network can still observe that encrypted traffic exists and may infer information from endpoints, timing and volume.
HTTPS is a major security control, but it is not a complete security system. The UK National Cyber Security Centre makes the same practical distinction: TLS protects data in transit, while application security, software patching and other controls remain necessary.
HTTPS vs HTTP
HTTP describes requests, responses, methods, status codes, headers and representation semantics.
HTTPS uses the same web semantics while carrying the exchange over TLS.
Plain HTTP does not provide TLS confidentiality, integrity or server authentication.
HTTPS URLs use the https scheme. HTTP and HTTPS are therefore different URI schemes even when they refer to related resources.
A website can redirect an HTTP request to HTTPS, but the initial HTTP request occurs before that redirect is received. HSTS can instruct a supporting browser to use HTTPS for a host without first attempting ordinary HTTP on subsequent visits; preload mechanisms can extend that protection to the first visit for preloaded hosts.
What is TLS and why is SSL different?
TLS is the modern security protocol used by HTTPS. SSL was its predecessor. The NCSC states that all SSL versions are formally deprecated and insecure, and that TLS 1.0 and TLS 1.1 are also deprecated. Its current guidance recommends TLS 1.3 and/or properly configured TLS 1.2 for systems that require those versions.
For current UK security guidance, see the NCSC's Using Transport Layer Security to protect data.
What happens during a TLS handshake?
The exact messages depend on the TLS version and configuration, but the purpose is consistent: agree how to protect the session, authenticate the server, and establish shared keying material without sending the resulting traffic keys across the network as ordinary plaintext.
Client and server exchange supported TLS capabilities.
The server supplies authentication material, normally including its certificate chain.
The client checks whether the certificate is acceptable for the hostname and trust policy.
Cryptographic key agreement derives shared secrets.
Each side derives traffic keys and begins exchanging protected application data.
TLS 1.3 streamlined the handshake and removed a number of older cryptographic options. It can also support 0-RTT early data in suitable applications, but early data has replay considerations and should not be treated as equivalent to ordinary post-handshake data for every operation.
What is an HTTPS certificate?
An HTTPS certificate is a digital certificate used during TLS authentication. It binds public-key information to one or more DNS names and is signed through a certificate chain that the browser can validate against trusted certificate authorities.
Domain name: the requested hostname must be covered by the certificate.
Validity: certificates have defined validity periods and must be current.
Issuer and chain: the browser needs a valid path to a trusted root under its policy.
Public key: the certificate carries public-key information used in authentication.
Revocation and policy checks: browsers and operating systems apply additional security logic according to their implementation.
A certificate does not certify that a site's claims, products or downloads are trustworthy. The NCSC notes that modern browsers treat Domain Validation, Organisation Validation and Extended Validation certificates equivalently in functional and security terms, and recommends Domain Validation certificates for web PKI use cases.
Why can an HTTPS certificate show a warning?
The certificate has expired or is not yet valid.
The hostname does not match the names covered by the certificate.
The certificate chain cannot be validated to a trusted root.
The server is presenting an incomplete or incorrectly configured chain.
The device clock is wrong enough to break validity checks.
Security software, a captive portal or an organisation's inspection system is intercepting TLS and the client does not trust the presented certificate.
Does HTTPS hide the website you visit from your ISP?
HTTPS encrypts the HTTP application data, including URL paths and page contents, once the TLS connection is established. It does not make the entire network path invisible. Your ISP still carries the packets and can see network-level information such as the remote IP addresses contacted, connection timing and traffic volume. DNS behaviour and TLS metadata can also reveal information depending on the protocols and privacy features in use.
This is different from a VPN, which can move selected network traffic through a separate encrypted tunnel to a VPN endpoint. HTTPS and VPNs operate at different layers and solve different problems.
Does HTTPS work differently on FTTP, FTTC or mobile broadband?
The security model does not fundamentally change with the UK access technology. Whether the device reaches the internet over FTTP, FTTC, cable, fixed wireless or mobile broadband, HTTPS still protects the TLS connection between the participating endpoints. The access network changes the path, performance and potentially the addressing environment; it does not replace TLS.
On very fast FTTP or multi-gigabit connections, TLS processing can become one component of end-to-end performance, but modern hardware and software are normally highly optimised. Real application throughput can still be limited by the server, CDN, latency, packet loss, congestion, device CPU, browser, WiFi, Ethernet or other parts of the path.
Does HTTPS slow down broadband?
HTTPS adds cryptographic work and requires a TLS handshake, but the practical impact cannot be reduced to a fixed percentage. Connection reuse, TLS 1.3, session resumption, HTTP/2 or HTTP/3 behaviour, CPU acceleration, server distance and application design all affect the result. On a modern system, the security benefit normally outweighs the modest protocol overhead.
The first connection can incur extra round-trip work compared with sending an unprotected HTTP request immediately. That does not mean a broadband speed test should be expected to lose a particular number of megabits per second merely because it uses HTTPS.
HTTPS with HTTP/1.1, HTTP/2 and HTTP/3
HTTP/1.1 can be used over TLS for HTTPS.
HTTP/2 is commonly deployed over TLS on the public web, with protocol selection negotiated between client and server.
HTTP/3 runs HTTP semantics over QUIC rather than TCP; QUIC integrates TLS 1.3 for its cryptographic handshake and protection.
The important point is that HTTPS is not tied to one transport generation. The web protocol stack has evolved while retaining the core requirement that secure web traffic receives appropriate cryptographic protection.
What is HSTS?
HTTP Strict Transport Security (HSTS) is a policy a website can send in the Strict-Transport-Security response header to tell supporting user agents to interact with that host using secure connections. It helps prevent accidental or attacker-induced downgrade to ordinary HTTP after the policy is known.
HSTS is standardised in RFC 6797. The NCSC recommends HTTPS-only publication, HTTP-to-HTTPS redirection and HSTS for web servers, with careful deployment appropriate to the service.
What is mixed content?
Mixed content occurs when a page loaded over HTTPS tries to load some subresources over insecure HTTP. Browsers restrict or block many forms of mixed content because an unprotected resource can undermine the security of the otherwise protected page. Site operators should serve page resources over HTTPS and remove insecure dependencies.
How to troubleshoot an HTTPS error
Check the exact hostname and make sure you have not followed a lookalike or mistyped domain.
Check the device date, time and time zone.
Try a current browser or application and install pending security updates.
Inspect the certificate warning rather than bypassing it. Note the hostname, issuer, validity and error reason.
Test another network only as a diagnostic step. A captive portal or TLS-inspecting network can change what certificate is presented.
If you operate the site, test the server certificate chain, hostname coverage, supported TLS versions and redirects.
Check for mixed-content or application errors separately from certificate errors.
Do not assume a broadband fault merely because one HTTPS site fails; compare multiple independent HTTPS services.
If many unrelated secure sites suddenly show certificate errors on one device, investigate the device clock, security software, trust store and network interception before blaming the broadband access line. If only one hostname fails, the problem is more likely to be specific to that service or its TLS configuration.
HTTPS misconceptions
HTTPS means the website is safe: false. It means the connection has the expected TLS protections when validation succeeds.
HTTPS hides everything from the ISP: false. It protects HTTP content, not all network metadata.
The padlock proves the business is legitimate: false. Certificate validation is not a general endorsement of the organisation.
SSL and TLS are interchangeable current standards: false. SSL is deprecated; TLS is the modern protocol family.
HTTPS prevents malware: false. A malicious download can itself be delivered over a perfectly valid HTTPS connection.
HTTPS FAQs
What does HTTPS stand for?
HTTPS stands for Hypertext Transfer Protocol Secure. In modern web use, it means HTTP communicated over a TLS-protected connection.
Is HTTPS encrypted?
Yes. TLS encrypts protected application data in transit between the TLS endpoints. That does not mean the data remains encrypted after it reaches an endpoint.
Is HTTPS the same as TLS?
No. HTTP is the application protocol and TLS is the security protocol protecting the connection. HTTPS is the use of HTTP over TLS.
Is port 443 always HTTPS?
TCP port 443 is the conventional port for HTTPS, but a port number alone does not guarantee which application protocol is actually running. HTTPS can also be exposed on other ports.
Can a phishing site use HTTPS?
Yes. An attacker can obtain a valid certificate for a domain they control. HTTPS can therefore secure your connection to a phishing site; users still need to verify that the hostname and service are legitimate.
Should I bypass a certificate warning?
Normally, no. A certificate warning means the browser could not establish the expected trust relationship. Investigate the cause rather than treating the warning as a routine inconvenience.
Key takeaway
HTTPS is HTTP protected by TLS. It gives web traffic confidentiality, integrity and server authentication in transit when correctly configured and validated. It does not make a website trustworthy, anonymous or immune to compromise. For broadband users, the most useful mental model is simple: HTTPS protects the application conversation across the network path, while the access network, endpoints and website itself still have their own security and performance responsibilities.
To explore the related technical concepts used in this HTTPS (Hypertext Transfer Protocol Secure) guide, visit our broadband terminology guide.
