Every URL starts with a protocol, a name which identifies how it should be processed. The name is followed by “://”. On the Web, it’s almost always either HTTP or HTTPS. The protocol name is followed by the character sequence “://”, to the annoyance of people entering it on a phone or tablet. The browser may let you leave it out when typing, but it has to guess it for you. When you create a link in an HTML page, you always have to include the protocol, e.g., https://www.example.com.

The difference between the two is that HTTPS provides security and HTTP doesn’t. An HTTPS link uses the TLS (transport layer security) communication protocol, which often goes under the obsolete name of SSL. In common usage, SSL and TLS mean the same thing. It gives you three advantages over plain HTTP:

1. It encrypts the data in transit in both directions. Anyone intercepting the data will find it effectively impossible to tell what information is being sent back and forth. They can, however, tell what domain you’re communicating with.
2. It verifies the identity of the domain you’re getting data from. With an HTTP connection, someone in the middle (e.g., a public Wi-Fi hotspot) can impersonate the domain.
3. It prevents alteration of data in transit. Only the holder of the TLS certificate can encrypt the data correctly. Any attempt to alter it will only turn it into gibberish.

HTTPS URLs provide another advantage which is less technical in nature. Search engines, notably Google, give them better treatment. All else being equal, you’ll get a better search rank with HTTPS URLs than with HTTP. For this reason as well as the security concerns, some customers insist that all links in a submission must be HTTPS. This is fine, except when a link that you want to include isn’t available in HTTPS. There isn’t much you can do in that case.

You can’t, in general, change HTTP to HTTPS in a URL and expect it to work. It’s worth trying, and in many cases it will work, but there’s no guarantee. Unless the website you’re linking to implements HTTPS, the link will get you a 404 error. Theoretically, HTTP and HTTPS URLs which are the same except for the protocol could deliver different content, though this is rare.

Most browsers will check if there’s an HTTPS equivalent to an HTTP URL and upgrade automatically to it if it’s available. In fact, too many browsers aggressively try to keep users ignorant of which protocol they’re using. They hide the protocol part of the URL in the address bar. When you’re putting a link into a page, you shouldn’t count on the browser to do the protocol upgrade for you. Having an HTTP link may weaken the page’s SEO. It could slow the page down a trifle, since the browser has to do an extra check. The link you provide should be the right one.

It’s equally important to remember what HTTPS doesn’t do. It doesn’t guarantee that the domain you’re reaching is legitimate or safe. If you connect to “noreallythisismicrosoft.com”, you’re almost certainly not connecting to a Microsoft-owned site, whether the link uses HTTPS or not. Even if the site is legitimate, it doesn’t guarantee that it hasn’t been infected by malware. The protocol ensures that the data will reach the server securely. It can’t guarantee that the server itself is free of security problems.

What does it mean for writers?

When you’re writing for a client, the first rule is to make the client happy. If they want only HTTPS URLs, that’s what you give them. If they’re OK with HTTP URLs, still try to give them HTTPS whenever you can. It gives the best SEO results and lets the user know that the link is secure. But make sure the HTTPS link actually works.

A few sites use self-signed TLS certificates. Their owners are either extremely stingy or extremely confused. A normal certificate includes confirmation from a certificate authority (CA) that the data you get back comes from the domain’s owner. An unsigned certificate just says, “I’m the domain’s owner,” which anyone can say. Browsers give alarming warnings about self-signed certificates, discouraging people from visiting the page. Free, signed certificates are available, so there’s no good reason to use a self-signed one for anything but internal testing. You may not be able to convince your customer that it’s a bad idea, to say nothing of the owners of third-party sites, but you should be aware that such links will scare viewers off.

If a link to a site which asks for a password or a credit card number uses plain HTTP, that shows serious disregard for security. Several browsers will issue warnings when opening those pages. Avoid linking to them if you possibly can. If it’s a site which just delivers static content, though, it’s not really horrible. Follow your customer’s preferences and don’t worry too much.