URL as UI: From Technical Protocols to Action Shortcuts

Recently, I had the opportunity to observe a group of college students taking an assessment. When asked to visit a specific URL, almost everyone painstakingly typed out the full prefix — character by character, starting with https://www.. Watching this made me pause. We spend so much time learning advanced frameworks, tools and technologies, yet we rarely stop to examine how the foundational layers of the web actually work.

It reminded me of a quote a friend shared with me a long time ago:

"It is the close observation of little things which is the secret of success in business, in art, in science, and in every pursuit in life." — Samuel Smiles, Self-Help (1859)

The address bar stopped being a place where you type a file path a long time ago. It is closer to a command line now, and for everyday navigation the https://www. is doing almost nothing. So I went and looked at what does happen when you type into it, using the browser's own diagnostics rather than my assumptions, and at how product teams have built whole experiences on the URL itself.

What the browser was already doing

I started with the address those students were effectively typing. A fresh copy of Chrome, no history, no account:

you type      http://google.com
Chrome        → https://google.com/       upgraded by the browser
Google        → https://www.google.com/   redirected by Google's server
you land on   https://www.google.com/

So two systems are each filling in a piece. Chrome supplies the https on its own, before Google is involved, and Google's server supplies the www because that is the address it prefers you on.

Type only google.com, which is ten keystrokes, and the address bar is already offering https://www.google.com/ before you press Enter. Type all twenty-two characters of https://www.google.com and you arrive at exactly the same page.

Being careful was a fair instinct. It just went into the part of the address that the browser and the website were already handling between them.

Part 1: the anatomy of a URL, and what actually needs typing

https://  www.  google  .com  /search?q=url
scheme    sub   domain  TLD   path and query

Part	Example	Why you can usually skip it	When you need it
Scheme	`https://`	Chrome tries the secure connection first on its own. For some domains it never tries anything else (more on that in Part 4).	Local development (`http://localhost:3000`), other protocols, and plain-text fields that only turn an address into a link when it starts with a scheme.
Subdomain	`www.`	It is a name the site owner chooses. Many sites redirect the bare domain to wherever they want you, as Google does.	When a site hasn't set up its bare domain to point anywhere.
Domain and TLD	`google.com`	You can't. This is the name someone registered, and it is what the browser looks up.	Every time you go to a site directly.
Path and query	`/search?q=url`	Only matters if you want a specific page or state, not the home page.	Linking straight to a product, an article, or a filtered view.

Part 2: three ways to name a place

Not every address reads left to right the way www.google.com does.

The familiar kind is a subdomain inside a company's domain, like docs.google.com or mail.google.com. google.com is the registered name and docs is one department within it.

Then there are brands as top-level domains: blog.google, design.google. When ICANN opened up top-level domains, companies could apply to run their own, so here .google sits where .com would and blog is the name registered under it.

The third kind turns an action into the top-level domain — slides.new, doc.new, repo.new. Google runs the .new registry, and its registration policy has an unusual rule: every .new address must take you straight into an action or a creation flow. A .new domain that just shows a marketing page breaks the rules.

Part 3: designing user journeys around the URL

For product designers and engineers, the URL is the first piece of interface a user touches, and it is there before the page has rendered anything.

Zero-click creation

The usual way to start a presentation is to open a tab, go to Google Drive, wait for it to load, click New, and choose Google Slides. The URL way is to type slides.new and press Enter. It skips the dashboard entirely and works like a keyboard shortcut for the whole web. Spotify (playlist.new), GitHub (repo.new) and Canva (design.new) all do the same thing.

Hackable URLs

A well-designed URL lets people navigate by editing it. On GitHub, change /issues to /pulls at the end of a repository's address and you get the pull requests. An address like site.com/app/v2/view?id=99482&type=dashboard gives people nothing to edit.

State you can share

When a shop writes your filters into the address — store.com/shirts?size=m&color=black — the view becomes something you can copy and send to someone else.

Redirects that forgive mistakes

Good sites decide whether they live at www or not and quietly redirect the other one, and handle /about and /about/ as the same page. Some go further: gogle.com sends you to Google, at least over plain http (over https it fails with a certificate error).

Part 4: what happens when you type slides.n into Chrome

Chrome has a diagnostics page, chrome://omnibox, that shows what the address bar is doing with every keystroke. I typed slides.n into it in two fresh copies of Chrome: one that had never visited slides.new, and one that had visited it once.

It starts before you press Enter

Each keystroke goes out to several sources at once: your history, your bookmarks, shortcuts you've used before, Chrome's built-in pages and your search engine's suggestions. Each answer comes back with a relevance score, and Chrome picks one to be the default: what Enter will do.

Chrome first has to guess what kind of thing you typed. For google.com it decided "url". For slides.n it decided "unknown" — it couldn't tell whether you were typing an address or a search.

Never visited

slides.n – Google Search          851   ← Enter searches Google
slides.nee                        601
slides.new google                 600
slides.nw                         553
...
slides.new as an address          not offered

Every row came from the search provider. Your history had nothing to say, and slides.new didn't appear as an address at all — only as part of a search suggestion. (It isn't a blanket rule: for a never-visited google.com, Google's own suggestion made the address the default. For slides.n, nothing did.)

Visited once

slides.new                        1413  ← Enter goes to slides.new, "ew" filled in
slides.n – Google Search          851

One visit is enough to change that. Your history now offers slides.new with a score of 1413, and Chrome fills in the last two letters for you. That 1413 isn't arbitrary: it is a constant in Chrome's source code, the score reserved for the best match the browser is willing to complete inline.

The scores aren't the whole story, either. The row for slides.new also carried the output of a machine-learning model, so the ranking isn't only fixed rules. The whole thing, every source asked and every answer ranked, finished in 67 milliseconds with the history and 84 without.

Getting ready before you commit

Chrome also keeps a record of what you tend to pick after typing a given input. If it is confident enough, it can start connecting to the site, or even load the page in the background, before you press Enter. In Chrome's source the defaults are a confidence of 0.5 to start loading the page and 0.3 to open a connection, and Google can change them through field trials. I didn't measure whether that happened in my runs.

Pressing Enter

For slides.new, the insecure version of the address never leaves your machine. The whole .new domain — along with .google, .dev, .app and .page — is on a list of HTTPS-only domains built into Chrome. When I asked for http://slides.new, Chrome rewrote it internally and gave "HSTS" as the reason.

That's a different mechanism from the Google example earlier. google.com isn't on that list. Chrome upgraded it anyway, under a separate feature it calls HTTPS-Upgrades.

Then Google's server takes over: slides.new redirects to the "create a presentation" address in Google Docs, which opens a new deck — or, if you're signed out as my test browser was, sends you to sign in first.

Try it yourself

Open chrome://chrome-urls and turn on the internal debugging pages. Current versions of Chrome have them switched off by default.
Go to chrome://omnibox.
Tick Show all details and type slowly.

Try an address you visit every day, then one you've never visited, and watch which sources answer.

Why this matters for builders

As building gets cheaper, understanding the mechanisms underneath is what opens up new opportunities and new ideas.

The students in that room were applying precision, which is a good habit. What they didn't have was a map of which layer was doing what, so the care went to a layer that didn't need it.

More of the stack is being handled for us now, by browsers and frameworks and increasingly by models that write the code. That makes it easier to spend attention on what is already automated and to miss what isn't. The teams behind .new worked with domains and redirects that already existed, and understood them well enough to see an experience hiding in them.

Look closer.

How this was measured: Chrome 156 on a Mac, running headless with fresh signed-out profiles, 7–12 November 2026. Search suggestions vary by time, place and account, so yours will differ. Scores and timings are from one machine.