HTTPS (HTTP Secure) encrypts web traffic using TLS (Transport Layer Security). It's required for modern web security, SEO, and accessing modern browser APIs.
Understanding HTTPS is essential because it protects every interaction between your users and your server. With over 95% of web traffic now encrypted, HTTPS is no longer optional—it's the baseline expectation. Google also uses HTTPS as a ranking signal, making it important for SEO.
Key Takeaways
- 1HTTPS uses port 443 by default
- 2TLS encrypts data in transit
- 3SSL certificates verify domain ownership
- 4HSTS forces HTTPS connections
- 5Required for service workers, geolocation, and more
"HTTPS is the use of TLS to secure HTTP connections. TLS provides endpoint authentication, confidentiality, and integrity. The TLS protocol aims to provide privacy and data integrity between two communicating applications."
HTTPS URL Structure
HTTPS URLs look nearly identical to HTTP URLs, with the only visible difference being the protocol. However, behind the scenes, TLS encryption wraps all communication between client and server.
# HTTPS URL components
https://example.com:443/path/page?query=value#fragment
# Components:
https:// - Scheme (secure HTTP)
example.com - Host
:443 - Port (443 is default, usually omitted)
/path/page - Path
?query=value - Query string
#fragment - Fragment
# Default port
https://example.com # Port 443 (implicit)
https://example.com:443 # Port 443 (explicit, same as above)
https://example.com:8443 # Non-standard HTTPS portThe structure above shows that HTTPS URLs use port 443 by default (versus 80 for HTTP). When you see a URL without a port specified, browsers automatically use the default port for that protocol.
The security in HTTPS comes from the TLS protocol that encrypts the connection. Let's look at the evolution of these encryption protocols.
TLS/SSL Encryption
TLS (and its predecessor SSL) has evolved through multiple versions, with older versions deprecated due to discovered vulnerabilities. The table below shows which protocols are safe to use today.
| Protocol | Status | Notes |
|---|---|---|
| SSL 2.0 | Deprecated | Security vulnerabilities |
| SSL 3.0 | Deprecated | POODLE vulnerability |
| TLS 1.0 | Deprecated | Legacy, being phased out |
| TLS 1.1 | Deprecated | Legacy, being phased out |
| TLS 1.2 | Current | Widely supported |
| TLS 1.3 | Current | Fastest, most secure |
Modern servers should support TLS 1.2 and 1.3 while disabling older versions. TLS 1.3 offers improved performance with faster handshakes and stronger security defaults.
TLS encryption requires a certificate that proves your domain ownership. Let's explore the different certificate types available.
SSL Certificates
SSL certificates serve two purposes: encrypting traffic and verifying that you own the domain. Different certificate types provide different levels of verification, from basic domain control to full organizational identity confirmation.
# Certificate types
# Domain Validation (DV)
# - Verifies domain ownership
# - Quick to obtain (minutes)
# - Free (Let's Encrypt) or low cost
# - Good for most websites
# Organization Validation (OV)
# - Verifies business exists
# - Takes days to obtain
# - Shows organization in certificate
# - Good for businesses
# Extended Validation (EV)
# - Extensive verification
# - Takes weeks to obtain
# - Historically showed green bar (no longer)
# - For high-trust sites (banks, government)
# Wildcard certificate
# *.example.com
# Covers all subdomains: www, app, api, etc.
# Single certificate for entire domainFor most websites, a free DV certificate from Let's Encrypt provides sufficient security. Wildcard certificates are convenient when managing multiple subdomains, covering all of them with a single certificate.
Once you have HTTPS working, you should enforce it permanently using HSTS—a header that tells browsers to always use HTTPS for your domain.
HSTS (HTTP Strict Transport Security)
HSTS instructs browsers to automatically upgrade all HTTP requests to HTTPS, even if a user types http:// or clicks an HTTP link. This prevents downgrade attacks and protects users from accidentally using insecure connections.
// HSTS forces browsers to use HTTPS
// HTTP response header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
// Components:
// max-age=31536000 - Remember for 1 year
// includeSubDomains - Apply to all subdomains
// preload - Submit to browser preload list
// Express.js
app.use((req, res, next) => {
res.setHeader(
'Strict-Transport-Security',
'max-age=31536000; includeSubDomains; preload'
);
next();
});
// With helmet middleware
const helmet = require('helmet');
app.use(helmet.hsts({
maxAge: 31536000,
includeSubDomains: true,
preload: true
}));
// HSTS Preload
// Submit your domain to hstspreload.org
// Browser will never attempt HTTP for your domainThe code above shows how to add HSTS headers in Express.js, both manually and with the helmet middleware. The preload directive allows you to submit your domain to the HSTS preload list, which is built into browsers—meaning they'll never even attempt HTTP for your domain.
Even with HTTPS and HSTS configured, you can still have security issues if your page loads resources over HTTP. This is called mixed content.
Mixed Content
Mixed content occurs when an HTTPS page loads resources (scripts, images, stylesheets) over HTTP. Browsers block or warn about this because it undermines the security of your encrypted page.
<!-- Mixed content: HTTPS page loading HTTP resources -->
<!-- Blocked (active mixed content) -->
<script src="http://example.com/script.js"></script>
<iframe src="http://example.com/frame.html"></iframe>
<!-- May be blocked (passive mixed content) -->
<img src="http://example.com/image.jpg">
<video src="http://example.com/video.mp4"></video>
<!-- Solutions -->
<!-- 1. Use protocol-relative URLs (deprecated) -->
<script src="//example.com/script.js"></script>
<!-- 2. Use HTTPS explicitly (recommended) -->
<script src="https://example.com/script.js"></script>
<!-- 3. Upgrade insecure requests -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
<!-- This header tells browsers to upgrade HTTP to HTTPS automatically -->Active mixed content (scripts, iframes) is blocked completely, while passive content (images, video) may show warnings. The best solution is using HTTPS URLs explicitly, or adding the upgrade-insecure-requests CSP directive to automatically upgrade HTTP resources.
Beyond fixing mixed content, you may need to programmatically verify SSL certificates—for monitoring, debugging, or building security tools.
Certificate Verification
Programmatically checking SSL certificates helps you monitor expiration dates, verify configurations, and debug TLS issues. The Node.js example below shows how to extract certificate details from any HTTPS connection.
// Check certificate in Node.js
const https = require('https');
function checkCertificate(hostname) {
return new Promise((resolve, reject) => {
const req = https.request({
hostname,
port: 443,
method: 'GET'
}, (res) => {
const cert = res.socket.getPeerCertificate();
resolve({
subject: cert.subject,
issuer: cert.issuer,
valid_from: cert.valid_from,
valid_to: cert.valid_to,
fingerprint: cert.fingerprint,
serialNumber: cert.serialNumber
});
});
req.on('error', reject);
req.end();
});
}
// Check expiry
const cert = await checkCertificate('example.com');
const expiry = new Date(cert.valid_to);
const daysUntilExpiry = Math.floor((expiry - new Date()) / (1000 * 60 * 60 * 24));
if (daysUntilExpiry < 30) {
console.warn('Certificate expires soon:', daysUntilExpiry, 'days');
}This code connects to a server and extracts certificate information including issuer, validity dates, and fingerprint. The expiry check at the end is useful for monitoring—Let's Encrypt certificates expire every 90 days, so automated checks help prevent outages.
Beyond security, HTTPS is required for many modern browser features. Let's look at which APIs only work on secure origins.
HTTPS-Only Browser APIs
Modern browsers restrict powerful APIs to secure contexts (HTTPS) to protect user privacy and security. If you need any of these features, HTTPS is non-negotiable.
| API | Purpose | HTTPS Required |
|---|---|---|
| Service Workers | Offline support, push | Yes |
| Geolocation | User location | Yes |
| Clipboard | Copy/paste access | Yes |
| Web Crypto | Cryptography | Yes |
| HTTP/2 | Performance | Yes (in browsers) |
| Payment Request | Web payments | Yes |
These APIs are blocked on HTTP because they access sensitive user data or device capabilities. Service workers, for example, can intercept network requests—a powerful feature that could be exploited if allowed on insecure connections.