Writing out web addresses

Here’s a question I’ve seen a few times of late: when writing out a web address, 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:

Components of a web address

Keeping with protocol

Web addresses begin with a ‘protocol’, the most common being http:// and https://.

From the technical point of view, the protocol isn’t usually required when quoting web addresses. To use the SfEP’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 https:// version.

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:

Trailing slashes

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 EspirianJohn Espirian (@espirian) is the SfEP’s internet director and principal forum administrator.

As a freelance technical writer, John specialises in producing online help content that’s actually helpful.


Proofread by SfEP Advanced Professional Member Etty Payne.

The views expressed here do not necessarily reflect those of the SfEP.

5 thoughts on “Writing out web addresses

  1. Penny

    Hi John, that’s really helpful, thanks. I posted a query about this on the Editors’ Association of Earth facebook page the other day, and got just about as many different answers as there were characters in the domain names. Now I see why, because it’s not as cut and dried as one might think.

    I am currently editing a book that has a list of resources, four of which are URLs.

    The first three all have ‘https//’ protocols, but as you say, you don’t need to key that in to get to the site. The last one, ‘ELT Journal’, doesn’t have a protocol, and doesn’t even have a ‘www’ subdomain (as you’ll see if you go to their site). However, if you type it in with ‘www’ at the start, you do get redirected to the site anyway. My provisional solution has been to do the following:

    The Teacher Trainer: http://www.tttjournal.co.uk
    English Teaching Professional: http://www.etprofessional.com
    Modern English Teacher: http://www.modernenglishteacher.com
    ELT Journal: http://www.eltj.oxfordjournals.org

    Now they are consistent, at least, and they all get you to the desired place, even though none of them are strictly ‘correct’. I tried leaving off the ‘www’ for each, but they did seem to be floating a bit, and didn’t look very much like URLs without that tell-tale prefix. Would you agree that this is the best solution? Thanks very much 🙂

  2. John Espirian

    If you’re certain that the first three URLs work correctly using the standard protocol (http://) rather than the secure protocol (https://), then it ought to be fine to present them as you have. However, there’s nothing inconsistent or wrong about including the secure protocol when that’s the form you’ve been given to start with. As it happens, a couple of the URLs you list introduce a further complexity, which is that their https:// forms don’t result in the display of a browser ‘padlock’ (the visible stamp of genuine security). You may be interested to see the results of the tests that this website can run for you: https://www.whynopadlock.com/

    With regards to your last example, I wouldn’t personally recommend introducing a phantom ‘www.’ to the address, unless the intended readership is such that not starting all addresses in this way would be very likely to confuse them. The presence of the protocol ought to be enough of a signal that this is a web address, and so ‘www.’ can be safely omitted.

    As you’ve realised, this is not an easy subject to get absolutely right – and, as with most editorial quandaries, there often isn’t an approach that is absolutely right.

  3. Melanie Thompson

    Hello John

    Nice article!

    It might be worth adding to it, for the benefit of the many editors who work on “other” documents (i.e. not print-only books/journals). For example, if you’re working on materials that will be converted to PDFs or for ebooks, websites and email newsletters, it’s fine to follow the house style for the visible part of a clickable link, but you do need the full address for the active part, which is hidden from view.

    Also, today I happen to spot some links that appeared to require the protocol but not the subdomain – what’s that all about? (http:// but no www)


  4. John Espirian

    Yes, when it comes to coding links for digital publication, you’d certainly be well advised to include the full URL in the code even if a shorter version of it is what’s actually visible to the end user. For example (I hope this comes through correctly):

    <a href=”http://www.espirian.co.uk/”>www.espirian.co.uk</a>

    I’d be interested to see examples of URLs that don’t work if no protocol is specified.


Leave a Reply

Your email address will not be published. Required fields are marked *