Here’s a question I’ve seen a few times of late: when writing out web addresses, must we include the whole address or is it safe to omit part of it?
Some house styles set out guidelines for writing web addresses. One would think, then, that the practice is simply a matter of style. In fact, it mostly is – but not always.
So that we know the names of the components that make up a web address, let’s take a look at an annotated example:
Keeping with protocol
Web addresses begin with a ‘protocol’, the most common being
From the technical point of view, the protocol isn’t usually required when quoting web addresses. To use the CIEP’s own website as an example, all modern browsers will treat the following addresses as equivalent:
When it comes to being consistent, we wouldn’t usually want both styles of web address to appear in the same piece of work.
The complications tend to come about when we start introducing addresses with other protocols to the same document. For example, if we wanted to make specific reference to a secure website, it would be correct to indicate this by including the protocol in the address, such as:
The intelligent reader will see the protocol and immediately understand that the website is secure, regardless of any other information about the site in the text.
Almost every website that has a secure area will also have rules that discreetly redirect users from the standard protocol (
http://) to the secure protocol (
https://). To demonstrate this, one can visit the following address:
Now, because a protocol hasn’t been included in the example above, the browser will try to take the user to the
http:// version of the site (this is the default behaviour of all web browsers). Seeing that action, the server running the website will automatically and immediately redirect the user to the
In short, this means that, even for secure websites, a protocol isn’t usually required in the address. I write ‘usually’ because there are some rare cases where web servers may display the wrong page if the secure protocol is not specified.
In cases where any protocols are included so as to give the reader a cue, it stands to reason that all other web addresses in the same document should also include protocols, on grounds of consistency.
In a document where standard web addresses are the only ones used (i.e.,
http:// and nothing else), it seems unnecessary to include the protocol. Omitting the protocol is both consistent and technically correct.
Handling new domain names
One common reservation with omitting protocols is when it comes to the newer domain suffixes, many of which most readers may not have heard of. Here are some examples:
If you saw these in running text, would you know that they were web addresses? Or might you think they were the ends and beginnings of unspaced sentences? The caveat here is that if unusual or novel addresses are used in a document, they might be worth qualifying with a protocol – and in turn that would require every other address in the document to include a protocol, too (on the assumption that we’re going to be rigid about consistency).
The cautious editor could use this argument to recommend that protocols be included on all addresses, to prevent a major rekeying effort in the event that some novel address is later added to a work that had previously contained only run-of-the-mill addresses. You’d have to make a decision about whether this would be too cautious an approach. For what it’s worth, I’ve been omitting protocols for quite a while now, having previously been a staunch supporter of mandatory inclusion.
Omitting the ‘www.’ part of an address
Some people don’t know that it’s usually possible to omit the ‘www.’ part of a web address and still be able to retrieve the website. This part of the web address is known as the ‘subdomain’. Most web servers are set up so that the domain (the key part of the address) and the ‘www.’ subdomain each allow access to the website. Here is an example:
Unfortunately, it’s not always possible to omit what would otherwise be a redundant ‘www.’ from the address. Here are some examples:
A trailing slash is the forward slash character (/) sometimes added to the end of a web address. This should be added only to the end of a domain name or a folder name in the address. Here are some examples:
- www.example.com/ – correct
- www.example.com/folder/ – correct
- www.example.com/folder/file.html/ – incorrect
One might wonder why a trailing slash would ever be added to a web address, given that the website ought to be displayed just as well without it. The answer is that the appropriate use of the trailing slash eliminates one unnecessary request from your computer to the server, thereby reducing the load on the server. You might not notice any positive effect, but it’s still a good practice to adopt: very busy servers will run better if their load is lightened in any way.
Web addresses followed by punctuation
A web address directly followed by any punctuation mark has the potential to confuse, because some readers may incorrectly interpret the punctuation mark as being part of the address. Word processors and email programs can sometimes be guilty of this mistake, turning an otherwise correct address into a link that doesn’t work when clicked. Thankfully, this is less of an issue than it once was.
It’s quite easy to fall foul of the ‘address plus punctuation’ problem when copying and pasting an address. It’s therefore sensible to avoid directly following an address with a punctuation mark; however, if the context is clear or the readership is web savvy, there may be no need to reword the text.
In my opinion, the omission of a terminal punctuation mark for the sake of clarity is preferable to the occasional practice of adding a space between the address and the punctuation mark. As usual, we should be consistent in the handling of all such matters.
If your client’s style guide sets out preferences for how to write web addresses, you should of course follow those preferences. But be mindful of any newer types of address that might confuse readers, and check that all addresses do indeed work as written.
If you have no style guide from which to work, remember that it’s perfectly fine to use the shortest possible address that will result in the desired website being loaded correctly.
John Espirian (@espirian) was the CIEP’s (then SfEP’s) internet director and principal forum administrator.
As a freelance technical writer, John specialises in producing online help content that’s actually helpful. He is also a relentlessly helpful LinkedIn nerd.
Proofread by CIEP Advanced Professional Member Etty Payne.
The views expressed here do not necessarily reflect those of the CIEP.