In olden times, when you were looking at a web page in a browser, you’d always see the full URL in the address bar above it — at least, as much as would fit. In most browsers, this is still the case.

But if you’re using Safari for iOS or Mac, it shows only the domain name, leaving off anything to the right, such a path and filename. You can only see what’s to the right of the domain name when you tap (or click) on the address bar in order to bring it into editing mode.

Here, I’ll argue that this is a bad thing.

(Thankfully, you can, at least for now, optionally set Safari for Mac to show full web addresses.)

Apple introduced this URL-truncating behavior with iOS 7 along with a dramatic redesign of the OS. Safari for Mac followed a year later with Yosemite. (Update: apparently Chrome on Android does this too.)

The philosophy behind many of those design changes was to remove extraneous or decorative elements, leaving only the bare essentials of the interface. In some cases, UI elements disappear from the screen completely in order to give content the sole focus.

Many of these changes have arguably been detrimental to iOS’s usability, and have been widely debated and discussed elsewhere. Here, I’ll focus on the URL issue.

I’m not sure if Apple has ever bothered to articulate the rationale behind this change, but if they did, it would probably sound something like this: In the context of the address bar, the domain name itself (e.g. example.com) is a concise way to help the user identify the site. It’s a cue that tells the user that the full web address is there and can be conjured up if tapped/clicked and then copied, edited, whatever. But the path, filename, query string, and whatever else can appear after “.com/” is technical, noisy, and often meaningless and normally there’s no reason for it to be visible to the user. Therefore, showing the entire URL is against Apple’s ethos of hiding technical details from users (and it could even compromise security).

So what’s wrong with this line of reasoning?

There’s usually useful information to the right of the domain name, and there are good reasons it should be visible even when the user hasn’t given focus to the address bar.

At the most basic level, when full addresses display, you know immediately whether you are on the site’s home page. If you only see a domain name, you’re at the main page. But the rest of the URL can also provide more fine-grained information about where you are.

To be sure, some web addresses contain unhelpful gibberish — for example, you used to come across a lot of articles with URLs like this:

news.com.com/2100-1083_3-5138072.html

But for reasons of human-readability and search engine optimization, most modern sites and content management systems these days generate more meaningful URLs that are easier for human beings to parse.

Consider some examples:

washingtonpost.com/politics/

washingtonpost.com/news/post-politics/wp/2015/09/15/white-house-formally-announces-chinese-president-xi-jinpings-first-state-visit-on-sept-25/

afar.com/travel-guides/france/paris/guide

afar.com/hotels/cusco-peru/belmond-palacio-nazarenas

freakonomics.com/books/superfreakonomics/

freakonomics.com/2014/05/07/testing-the-limits-of-google-translate/

It’s clear which URLs refer to articles or blog posts (the inclusion of a date is a big hint) and which point to other sorts of pages. And these addresses convey not only information about the content of particular pages, but about the information architecture of the website. For example, the first freakonomics.com link tells you that you’re looking at a page about a book called Superfreakonomics, but also suggests that you’re in a books section that presumably contains other pages about books.

This is not to say that users scrutinize every URL they come across — most are undoubtedly mostly ignored most of the time (although I’d argue that when it’s visible, the user unconsciously scans its information). And a page layout will surely give you cues that tell you what sort of page you are on and where you are in the site’s hierarchy if it’s designed well.

Unfortunately — this might come as a shock — not all websites are designed well. Many don’t give you a good indication of where you are. And especially on blogs, it can be unclear — especially in the above-the-fold portion of the page — whether you are on an individual post, the home page, or on a page showing all posts of a tag or category. With a full URL, this information is clear at a glance.

And even for sites that are thoughtfully designed, they all are done a little differently, and so it takes some extra cognitive effort to interpret a particular layout and its navigation cues. But there’s always a URL, and it acts as a concise but information-dense indicator of where you are and what sort of a page you’re on.

On iOS, Safari’s URL-hiding can be particularly annoying. Consider that on a cellular connection, data speeds can be quite slow, particularly if you have spotty coverage (i.e. you use T-Mobile). Say you launch Safari and it immediately begins to reload whatever is in the frontmost tab, which in this case says “facebook.com.” While it’s loading, the page is totally blank.

“It’s taking a long time to load, but when it does, I will see all of the delightful things that have been posted to my news feed!”

Oops, it was just a leftover tab from when I used Facebook to log in to a different site! Cue sad trumpet.

For this reason, I’m often faced with the decision of whether to tap on the URL in mobile Safari to make sure I’m going where I think I’m going, or just wait, taking the risk that I’m wasting time loading a page I don’t want to see. This unnecessarily introduces a situation where the user doesn’t know what’s going on, which is never a great thing in a UI.

In short, full URLs are concise, human-readable, metadata-rich info-nuggets, and there are plenty of good reasons not to hide the portion that often has the most useful information. I realize that this train has long left the station, but I remain a proud UI reactionary. Long live the URL!

P.S.Designers looking to mitigate the domain-name-only problem might wish to consider the example of the New York Times blogs, where some important information is placed in off to the left, not the right, in subdomains that are always visible in the address bar. It doesn’t solve the problem completely, but it’s a way to add some higher-level navigational landmarks to the address bar. (Unfortunately, mobile users are still redirected to a generic mobile.nytimes.com domain name.)

I’m not sure what the rationale of that construction is, as it has been the convention for NYT blogs since before iOS 7 was a thing. SEO probably had something to do with it, but I wonder whether they were also thinking about the UX of typing URLs. For instance, if you want to read Mark Bittman’s blog, you can just start typing “bittman” in the address bar, and, if you’ve visited before, the rest of the URL autofills, and then you only need to hit Enter.

P.P.S. For more on the UX of URLs, see this Jakob Nielsen piece from all the way back in 1999. The principles of good URL construction still apply. Fun fact: according to an eye-tracking study, “people spend 24% of their gaze time looking at the URLs in the search results.” I wouldn’t be surprised if this were still true.

The article contains this interesting passage: “It is likely that domain names only have 3-5 years left as a major way of finding sites on the Web. In the long term, it is not appropriate to require unique words to identify every single entity in the world. That’s not how human language works.” Nielsen was on the right track — Google and social media have made the act of typing in URLs a much rarer occurrence. Yet Nielsen’s prediction of the emergence of a superior addressing system has not come to pass.

Generally, if a piece of tech gets the job done reasonably well, it doesn’t change; change grows up around and on top of it. URLs, like TCP/IP and UNIX, are part of the lizard brain of the Internet.