Guides / Concepts explained

What Are HTTPS and SSL? How Secure Websites Work, Explained Simply

HTTPS encrypts the connection between a browser and a website using TLS (once called SSL). What certificates are, what the padlock means and doesn't, and fixes.

Mythex Team · 2026-09-29 · 5 min read

HTTPS is the secure version of HTTP, the protocol browsers use to talk to websites. It wraps every request and response in an encrypted connection using TLS (Transport Layer Security), so nobody between the visitor and the website can read or tamper with what's sent. SSL is the older name for the same idea — the original protocol TLS replaced — which is why people still say "SSL certificate."

Why HTTPS matters when you build with AI

Any app you publish should be served over HTTPS. That's not only good practice:

• Browsers expect it. Sites on plain HTTP get labelled "Not secure," and some browser features — such as location access, camera and microphone, and service workers for offline apps — generally only work on secure (HTTPS) pages.
• Logins and forms. Without HTTPS, passwords, session cookies and form data travel in readable text. Anyone on the same café Wi-Fi could potentially capture them.
• Payments and third parties. Payment providers, OAuth sign-in and many APIs require HTTPS redirect and callback URLs.
• Trust and search. Visitors notice the warning, and Google has said it treats HTTPS as a ranking signal.

The good news: on most modern hosting platforms, HTTPS is set up automatically. What you mostly need is to understand the pieces well enough to fix it when a custom domain or a mixed-content warning goes wrong.

An everyday analogy

Sending data over plain HTTP is like mailing a postcard: every postal worker who handles it can read it, and someone could even change the message.

HTTPS is like sending a sealed, tamper-evident envelope — and first checking the recipient's official ID. The certificate is that ID card, issued by a trusted authority (the certificate authority) that has checked the website really controls the domain. The encryption is the sealed envelope. The ID proves you're writing to the right address; the envelope keeps the contents private.

How HTTPS works, simply

When a browser opens https://shop.example.com:

1. Hello. The browser connects and says which encryption methods it supports.
2. Certificate. The server sends its certificate, which says "this key belongs to shop.example.com" and is signed by a certificate authority.
3. Check. The browser verifies the signature against authorities it already trusts, checks the certificate hasn't expired, and checks the domain matches.
4. Keys. Browser and server agree on a fresh secret key for this session, without ever sending it in the open.
5. Encrypted conversation. All requests and responses — pages, form data, cookies — now travel encrypted.

This TLS handshake takes a few milliseconds and happens automatically. The visitor just sees the padlock icon (or, in some browsers, a neutral site-info icon).

What HTTPS does and doesn't protect

HTTPS encrypts the contents of requests, including the page path and query string. But the domain name you visit is usually still visible to networks along the way. That's one reason never to put personal data in URLs anyway — they also end up in logs and browser history.

A worked example: connecting a custom domain

Say you publish a booking app and want it at book.myyogastudio.com:

1. You add a DNS record pointing book.myyogastudio.com to your host. See how domains and DNS work.
2. The host proves to a certificate authority that it controls that name — typically by responding to a challenge on that domain — and receives a certificate.
3. The host installs it and renews it automatically before it expires. Certificates are deliberately short-lived, so automatic renewal matters.
4. Visitors to http://book.myyogastudio.com are redirected to https://.

If step 1 is wrong — the record points elsewhere, or a proxy sits in the middle — step 2 can fail and visitors see a certificate error. That's the most common HTTPS problem people hit when connecting a custom domain.

Key terms

Common misconceptions

• "The padlock means the site is trustworthy." It means the connection is private and the domain matches. Scammers get certificates too.
• "HTTPS is only needed for payment pages." Any page with a login, a form or a cookie needs it — which is nearly every app. Just use it everywhere.
• "Certificates are expensive." Free, trusted certificates are standard, and most hosts manage them for you.
• "HTTPS makes my app secure." It secures the connection. Your app still needs server-side permission checks, safe secret handling and input validation. See the security checklist for AI-built apps.
• "HTTPS makes sites slow." Modern TLS adds very little overhead, and features like HTTP/2 that make sites faster generally require HTTPS in browsers.

Fixing common HTTPS problems

What to ask your AI builder

• "Make sure every image, script and font loads over HTTPS or a relative URL — no http:// links."
• "Redirect all HTTP traffic to HTTPS."
• "Set session cookies with the Secure and HttpOnly flags."
• "Use https:// for every OAuth, payment and webhook callback URL."
• "My custom domain shows a certificate error — what DNS record does the host expect?"

HTTPS in Mythex

When you connect a custom domain on Mythex (a Pro feature), you add a CNAME record pointing to your app's slug.mythex.ai address, click Verify, and Mythex issues HTTPS for the domain automatically. The docs cover the two most common snags: if your DNS is on Cloudflare, set the record to "DNS only" (grey cloud) rather than proxied, so Mythex can issue the certificate; and DNS can verify before HTTPS is fully set up, so wait a few minutes and verify again. See custom domains in the docs and our guide to connecting a custom domain.