How to Navigate to Web Pages Efficiently Without Using Navigation Menus
This guide explores ways to navigate to URLs more efficiently inside a web browser, with a focus on the Google Chrome and Mozilla Firefox browsers. It does not cover bookmarks or custom keyword searches, as these are often covered in other guides. This guide emphasizes typing words to navigate rather than clicking and navigating menus.
The main goal is to navigate more quickly to webpages, but the methods here, particularly Methods 2, 3, and 4 have two more benefits: (a) they can be used to quickly retrieve specific URLs to copy/paste into other content. For instance, if writing a blog post where you want to link to specific content you've already read, you can call up the URLs quickly, without even needing to revisit the pages, (b) by reducing the number of intermediate page loads needed to get to a page, they make it easier to work offline and with poor connectivity. In particular, you can call up a URL even while offline, switch to an existing open tab while offline, and visit a URL directly without an intermediate search engine query.
Part 1Summary Table
The table summarizes the various strategies for navigation covered later in this article, and helps you decide which strategies to use in a given situation.
Strategy What you need to remember about a page Pros Cons/caveats
Address bar A word that appears in the URL or title Easy to use and searching is fast In Google Chrome, the set of URLs that are searched is limited to those visited in the last 3 days or visited at least 4 times or typed at least once
History search A word that appears in the URL or title Easy to use and searches through all of your browser's history Searching is slower than the address bar
Site-specific URL manipulation A word that appears in the URL or title of a similar page You don't need to have previously visited the page Requires good understand of the website's URL structure; might require practice to get used to
Search engine (without site: operator) A word that appears in the URL, title, or body of the page You don't need to remember a word or phrase in the URL/title Without the site: operator, a search engine will search all of the internet, so you will possibly have to sift through many irrelevant results. Also, the method doesn't work for things indexed by search engines, such as private Google Docs, forums, wikis, and code repositories
Site-specific search (site's search box or search engine with site: operator) A word that appears in the body of the page and the website the page is on You don't need to remember a word or phrase in the URL/title Some sites have a bad search tool; others disable search engine indexing so the site: operator doesn't work
Browser's history database A word that appears in the URL or title Fully programmable/customizable once setup is complete Requires manual setup
Mirror of content A word that appears in the URL, title, or body of the page Search criteria more flexible Requires downloading content
Part 2Using the Address Bar for a Basic Search
The address bar (or URL/keyword navigation bar) is a bar at the top of the browser that displays the current webpage's URL. Most of the time when navigating to a specific page that you have visited in the past, you will be typing words from the URL or title of the page into this bar and selecting from the suggestions given by the browser. In Google Chrome, this bar is called the omnibox. In Mozilla Firefox, it is called the Awesome Bar.
If you can remember words from the URL or title of the page, that makes searching much easier (because the URL and title are what the browser remembers about the page). If you can only remember a phrase that appeared on the page, or an idea discussed on the page, locating the page is much harder.
The goal is to quickly find the page you are looking for. To do this, you want to type words that (1) identify the page of interest; and (2) identify as few as possible of pages that are not of interest. If you visit many pages on the English Wikipedia (en.wikipedia.org), then typing "wikipedia" will certainly identify the page of interest, but it will also find many other pages that are not of interest. The end result is that you will only find the most recent or most frequently visited pages on Wikipedia, rather than the specific article you are looking for. It is better to type some word from the article title.
A few notes:
For results from your history, both a title and a url will show up. Look at these to figure out if the page is the one you are looking for If you are seeing some results but not the ones you are looking for, continue to type in further keywords Once you find the result that is relevant, you can use keyboard arrows (on desktop/laptop) to navigate to the url, followed by ↵ Enter to go to it. Alternatively you can use a mouse-click to get to it.
It is possible that (1) you misremembered a specific word that appears in the URL or title (e.g. you remembered a synonym instead of the actual word); (2) the page uses a variant spelling (e.g. US vs UK spelling); (3) the word-breaking used in the URL or title is different (e.g. "commandline" vs "command-line" vs "command line", "CamelCase" vs "camel case").
The address bar in both Chrome and Firefox will allow you to directly search the web (using the default search engine or search engine specified in the settings). If the history-based suggestions are not helpful, try hitting ↵ Enter anyway to see if a search engine can help.
You can use this method on desktop/laptop to search within your existing open tabs as well: After you type in relevant keywords, the suggestions that correspond to existing open tabs will say so. In Chrome on desktop/laptop, this shows up as a "Switch to this tab" button on the right end of the suggestion. You need to click on that button to switch to the tab (if you do not have even screen width the button will appear with a box inside it, but with no text). Moreover, if you do this, and the tab in which you were typing the url was a brand-new one, that new tab will automatically close. If you click elsewhere in the suggestion it will open that page on your existing tab. In Firefox, clicking anywhere in the suggestion will take you to the existing open tab. Moreover, if you do this, and the tab in which you were typing the url was a brand-new one, that new tab will automatically close. If you want to create a new tab, you need to either type in the whole url yourself, or visit the existing tab and then right-click on the tab header, then use the "Duplicate tab" menu option. Another difference between Chrome and Firefox: in Firefox, existing tabs will show up in suggestions even if those tabs failed to load or gave errors. In Chrome, only tabs that succeeded in loading show up in suggestions. The option to switch to an existing tab does not seem to be available on mobile Chrome.
Part 3Using the History Search (Chrome)
History search means searching through your browser's entire history. To make the results appear quickly, the omnibox in Chrome limits the set of URLs it will search through, so history search is distinct from using the omnibox. (Firefox may or may not limit the URLs it will search through in the Awesome Bar.) If the URL you want to navigate to does not appear in the omnibox, another option is to use the browser history.
In Chrome on a desktop/laptop, you can go to the browser history by typing Ctrl+H or ⌘ Cmd+Y (on a Mac), or clicking Menu (⋮ or ☰) → History → History, or using the top menu → History → Show Full History, or typing chrome://history/ in the omnibox and hitting ↵ Enter. In mobile Chrome on Android, you should be able to navigate to history using either ⋮ → History or typing chrome://history/ in the omnibox and hitting ↵ Enter. In mobile Chrome on iOS, only the first method (⋮ → History) works. In Firefox on a desktop/laptop, you can use the top menu → History → Show All History
At the top is a search box that says "Search history". On mobile devices, this simply shows up as the search icon (magnifying glass) and you need to click on it to be able to search history.
Use the same general idea articulated in Method 2 of typing in the most unique identifying keywords when searching. This will allow you to narrow to the most relevant search results more quickly. Both Chrome and Firefox seem to delete old history, so if you last visited a page a long time ago, it may not appear in the history search. On both Chrome and Firefox, a page resulting in HTTP error codes like 404 will not be recorded in the history, so they will not show up in history-based searches (omnibox, history search).
Part 4Using Site-Specific URL Manipulation
If you haven't (recently) visited the specific URL you want, but you've visited similar URLs, then you can call up the similar URL and edit it by hand. If you frequently use a particular website, it may be worth trying to understand the URL structure of the website so you can navigate it more easily by editing similar URLs.
This builds upon Method 2: We use Method 2 to populate the address bar with a similar URL, then edit it manually. In particular, after seeing the similar URL in the suggestions, do not click it. Rather, if on desktop/laptop, use the arrow keys to put it in the address bar, then click in the address bar to edit it. On Chrome mobile, click on the arrow pointing up and left to the right of the suggestion to fill it into the address bar without initiating a visit to the webpage (so that you still have the opportunity to edit before visiting).
Example from GitHub: Suppose you have visited the URL https://github.com/jgm/pandoc/blob/master/doc/lua-filters.md before. Then you can type in the address bar lua filters to call up this stored URL. If you then want to see the version history of this file, you can change the blob to commits. If you want to see other files in the same directory, you can delete the filename lua-filters.md and change the blob to tree. In both of these cases, you can first visit https://github.com/jgm/pandoc/blob/master/doc/lua-filters.md and then click on a link on that page to navigate to the other pages. However, manipulating the URL will allow you to get to your destination without first loading the original page. Example from Wikipedia: Suppose you want to see the revision history of a particular Wikipedia page, X. Suppose also that you have visited at least one revision history page for a different Wikipedia article, Y. Then you can type wikipedia history in your address bar to call up https://en.wikipedia.org/w/index.php?title=Y&action=history, then change the Y to X to get https://en.wikipedia.org/w/index.php?title=X&action=history.
Part 5Using Site-Specific Search
Site-specific search means searching inside a specific website by using the website's search box or using the site: operator on a generic search engine. If you cannot remember a word that appears in the title or URL of the page you are looking for, then the address bar/history search approaches don't work. In this case, if you happen to remember a word that appears in the body of the page and you remember the website it was on, then using a site-specific search can be a good idea.
The search box will usually be in the top bar or left or right menu of the site. On smaller screens, the bar may not show up On smaller screens, the bar may not show up in full, but you may see a search icon (usually, a magnifying glass) that you can click on to show the search bar. For some sites, the search box may not be on the site pages, but there may be a separate search page you have to navigate to via the menus.
Note that unless you have strong reason to believe that the search box is good, you should keep open to the possibility that the page you are looking for may exist but still not show up. Some sites (such as the Wikipedia sites) have search autocomplete functionality, so they start showing results as you type queries in. However, even with these sites, typing in the full query and pressing ↵ Enter does a wider and more comprehensive search, and gives more results than the autocomplete. Thus, if autocomplete already shows you your desired results, that is good, but if not, you should type your full query.
If the site is using a standard software such as MediaWiki or CMS such as WordPress, you can read up on the search functionality for the software/CMS. For sites that are used as internal productivity and workflow tools, such as Jira, there are usually a lot of advanced search capabilities. Some sites support search faceting (filtering by author, tags, price range, or some other facet of the items being searched), boolean operators, and date ranges. In general, e-commerce sites are more likely to have good faceting support. Use these if they help.
operator if the website doesn't have a search box or only has a bad search box. For example, typing site:en.wikipedia.org the pillows on Google will search for the string the pillows on the domain en.wikipedia.org (i.e. the English Wikipedia).
Keep in mind that this works only for sites whose content is indexed by Google. In particular, it will not work for private Google Docs, private wikis, private forums, private GitHub repositories, or private Jira projects. This method may also miss some pages if the pages you are trying to reach have not been indexed by Google. This can happen if the site has low traffic and does not have a reliable sitemap or link structure for Google to be able to access all pages.
Part 6Using the History Database
On your computer, both Chrome and Firefox keep a SQLite database of your browser history. This means that if you are already familiar with databases, you can work with your browser history in the same way. For example, you can list all of your history, filter through some subset of your history according to arbitrary criteria (e.g. substring match, fuzzy search, regular expressions), and programmatically process your history. Working directly with the history database takes some preparation, in terms of locating the database, learning the structure of the tables, and looking for or writing custom tools. Therefore, most users will probably not want to do this.
An example of using the Chrome history database is Junegunn Choi's article "Browsing Chrome history with fzf". This article describes the steps for writing a shell function that queries the history database and searches the whole history using a fuzzy finder called fzf. The upshot is that one can type a command ("c" in the article) at the terminal to search through one's entire Chrome history using fuzzy search and open the found URL using Chrome.
Part 7Using a Full Mirror of the Content
A full mirror of a website's content means downloading the whole website onto your local computer. If you need to repeatedly search the same site, you may want to consider making a full local mirror of the website content (or some subset of it). This is especially the case if the site has a bad search box and cannot be searched by a search engine. The article How to Archive Websites on Unix Like Systems covers some considerations for how to mirror a website.
You frequently work with a specific repository on GitHub. Since GitHub repositories can easily be cloned, you can do this once and search through the repository using standard tools like your text editor/IDE and grep. You want to search through a personal archive, like your Gmail or Facebook Messenger messages, where the content is not public. These services often have a feature to export your personal content. Once downloaded, you can search through the results locally. You want to search through the contributions of a particular user on a website, but the website's search function doesn't allow you to filter by author. In this case, you can download all of the contributions of the user, then search locally.
Part 8Understanding How the Omnibox Works (Chrome)
This section talks about Chromium rather than Chrome, because the latter is based on the former and only the source code for the former is publicly available. For the purposes of quickly navigating to a particular URL, probably the most important takeaways from the way the omnibox works are: (1) a URL is suggested only if there is a match at a word boundary for at least one word you typed; and (2) the omnibox doesn't search all of your history, so if you can't find something that you know you've visited before, going to history search is a good idea. The rest of this section looks at the omnibox in more detail.
A provider gives suggestions to the omnibox. There are various providers, each giving a specific list of suggestions given some input (or no input). In the Chromium source code, each provider is an AutocompleteProvider. Two providers give history suggestions. These are HistoryURLProvider and HistoryQuickProvider. The former specializes in giving suggestions based on prefix matches for a URL. The latter can give suggestions based on non-prefix matches, and also matches words in the title.
For both HistoryURLProvider and HistoryQuickProvider, URLs are suggested only if visited in the last 3 days or visited at least 4 times or typed at least once. In particular, this means that the omnibox doesn't search through all of your browser history. This also means that you can make sure a page is suggested in the omnibox by visiting it once via the omnibox or by repeatedly clicking through to it. For a result to be suggested in the omnibox, each word must match somewhere in the URL or title. In addition, at least one word must match at a word boundary (e.g. after a dot or dash or space). There are some exceptions to the above: when the browser session length is longer than three days and you have visited the URL more than 3 days ago during the current session, the page can still be suggested even if it doesn't meet the "visited in the last 3 days or visited at least 4 times or typed at least once" condition. In addition, HistoryURLProvider can suggest a URL that hasn't been visited if you have visited a subpage of an intranet host. The constants that modify the behavior of the history providers are all hard-coded in the source code (they don't seem to be modifiable in the preferences). This means that if you don't like their behavior, you can just change the values of these constants and recompile (if you use Chromium).
Visit chrome://omnibox/ in Google Chrome. This is available on desktop/laptop and in Chrome on Android but not in Chrome on iOS. Type text and hit ↵ Enter or click Submit. Search results will appear for what would be suggested in the omnibox. Checking the different boxes like "Show all details" and "Show results per provider, not just merged results" will toggle the results to show more details.
Pages visited through the main browsing are available as suggestions in incognito mode (as long as the pages meet the regular requirements above), but pages only visited through incognito mode will not be available as suggestions, even in incognito mode. An exception to the above: Currently open tabs in incognito mode will show up with a "Switch to this tab" button if you type in the full URL in another tab, or if you type in keywords from the URL and title and the page is one that would show up as a suggestion in non-incognito browsing. There is no "Switch to this tab" option to switch to the tab in non-incognito, even if the page is open in a non-incognito tab.
On desktop/laptop, you can access and edit this setting as follows: Go to chrome://settings, then click on Advanced. You should see an option called "Use a prediction service to help complete searches and URLs typed in the address bar". Turning this off means more results from your history will show up in the omnibox because your history results are no longer competing with the search engine suggestions for spots. However, turning this off means not seeing any search engine suggestions (you will still see some of your own past search queries, just no additional search queries from the prediction service). The equivalent setting on mobile Chrome is under ⋮ → Settings → Advanced → Privacy and says "Search and URL suggestions" with subtext "Use a prediction service to show related queries and popular websites as you type in the address bar".
Part 9Understanding How the Awesome Bar Works (Firefox)
Firefox uses a frecency algorithm (a combination of "frequency" and "recency") to rank results in the Awesome Bar.
There are some remaining questions about this algorithm that are unclear:
The frecency algorithm seems to only affect the ranking of the results, rather than which URLs to rank in the first place. Must all words match at a boundary? Does it search through the whole browser history, or only some subset (like in Chrome)? How does the frequency and recency interact with the string match quality? For example, it wouldn't make sense to rank highly poor string matches, even if such a page is visited more often.
Pages visited through the main browsing are available as suggestions in a private browsing window (as long as the pages meet the usual requirements), but pages only visited through private browsing will not be available as suggestions, even in a private browsing window.