The HTML <LINK> tag (used for Navigation)



Everything on this web page should be applicable to the latest versions of HTML, except that recent HTML standards by W3C recommend or require the use of lowercase tag names. This web page was written with uppercase tag names because it was originally written for an older version of HTML. However, other than the lowercase/uppercase issue, the information in this document has remained relevant to the latest HTML standards that W3C publish.

Recognition (and lack thereof)

Support for the <LINK> tag, a valid part of HTML specifications, is so underused that many people, including professional web designers, are unaware of this standard tag. This leads to web designers implementing custom solutions to offer the navigation features described in the LINK tag specifications, not realizing that any HTML specification for such features even exists. There have been some extentions to the LINK tag's functionality, such as specifying FavIcon.ico shortcut icons, and specifying CSS style sheets, or even Microsummaries. These extensions may be far more well known than the tag's original purpose, which is to specify page relations so navigational tools can be used. Sometimes people spend a lot of effort creating custom solutions to implement the same basic functionality that the <LINK> tag was designed to do, yet people simply do not know that it exists. An example is this proposal for a new tag.

Example uses

As a quick example of how a LINK tag can be used, page 3 of a forum could have LINK tags to support hyperlinks to the previous page, the next page, or to go up in the heirarchy to a table of contents (or a list of forum topics or a list of forums).

Another example would be a page showing results of a query that was provided to a search engine.

In both of these example scenarios, if a web page uses this tag and a browser supports the tag, then a user can go from page to page using a navigation button in the browser. (At least in theory, the browser could also support a keyboard interface, similar to the Alt+Home keyboard combination that lets a person quickly go to the home page, without needing to move a person's hand off of the keyboard).

The other typically-used option for navigation is to make users scroll to the top or bottom of the page, in hopes that site-specific navigation hyperlinks are located there. Some sites don't place navigation hyperlinks in both locations (at the top and the bottom). So, if a user scrolls back up a bit to look at the middle of the page, and then decides to move onto another page, the user needs to just guess which direction to scroll to (which is why the user “hopes” to find navigation when scrolling to the first direction). That guessing isn't needed when the user has a familiar interface at a known visual location.

Browser Support

Most browsers can actively support the little-known <LINK> tag, even if the support simply comes from The linknav.js solution: browsers supporting JavaScript and CSS can support navigational features with the <LINK> tag. Webmasters may also wish to check out TOOGAM's section on LinkNav, which provides some another JavaScript file to update the functionality of LinkNav.

The other piece of really good news is that using the <LINK> tag does not cause problems. Browsers do not break when the <LINK> tag is used, even if they do not visually show any support for the <LINK> tag. Perhaps that is simply a pleasant side effect of the fact that the <LINK> tag is actually a very old part of HTML.

Some browsers also have support built-in (without requiring the use of any JavaScript). Support by the much more modern Mozilla SeaMonkey is documented by Link Bars. Actually, some even nicer support may be seen in the good implementation by the very old Moscaic browser version 1.1, which came with some sensible graphics on buttons (see by the bottom half of Idocs Guide to HTML: LINK). Another example of an early browser is the browser named Lynx, which operates in text-mode and shows the LINKs very clearly. Other browser support is documented by The LINK Element: Addendum.

Other browsers are not known to provide built-in visual support of the navigational features of the <LINK> tag, unless such support is added through the use of JavaScript or add-ons. The good news for webmasters is that, as mentioned earlier, the end-user experience can support this through JavaScript. For people who are browsing the web, that doesn't do any good for web sites that support the standard <LINK> tags but don't provide a JavaScript solution. Sadly, this is the experience that is provided for users of both Mozilla Firefox and Microsoft Internet Explorer, unless functionality is provided by add-ons. Pleasantly, such add-ons do exist and work well, so users who are ambitious enough to install an add-on can enjoy such benefits in the web browser of their choice.

The web browsers page may have some information for specific web browsers, such as Firefox add-ons: Supporting the <LINK> tag. For Internet Explorer 5+ on Win2K/XP, the “<Link> Navigation Bar”/“<LINK>-Bar” adds some support. There is no equivilent option for users of other versions of MS IE (such as MS IE 6 for Win9x).

Using the <LINK> HTML element/tag

Webmasters can support proper usage of the <LINK> tag when they are implementing features that are well-supported by the <LINK> tag. For instance, many web sites could use hyperlinks for listing a “Copyright” page, a “Start” (or “Home”) page, a Table of “Contents”, or the “Next” page in the series of pages. Details, on how to make such a <LINK> tag, are located on this web page.

Using these pages can brighten up some web browser features that would otherwise be dimmed (a.k.a. “grayed out”). Therefore, supporting the use of a “LINK” tag can make web browsing more pleasant for some users visiting a supporting site.

Further support can be provided, by adding support for those browsers that don't feature navigational controls but which do support JavaScript. Letting users know about this feature may help users who would appreciate such functionality, but simply would not know about the ability to use it. For the required software and JavaScript, check out: LinkNav.js website, which gives the usage of using linknav.js (local) and then linknav.css (local), and which points out that these files use Creative Commons Attribution-Share Alike 3.0 License. Also, check out TOOGAM's section on LinkNav for one more JavaScript file that may be useful.

To use a <LINK> tag, first find a possible common use of a link tag. Some common examples (like the Table of “Contents”) were mentioned earlier, and a larger list of commonly supported relationships is provided later.

Next, decide whether to use REL= or REV=. In most cases, REL= will probably be the logical choice. REL indicates that the relationship specified is how this page views the specified URL. For example, REL=Next indicates that the specified page is what this page would consider to be the "Next" page. In contrast, REV= indicates the relationship that the other page would indicate. For example, REV=Previous indicates that this page would be considered to be the “previous” page by whatever URL is specified.

Although the previous paragraph said REL= will likely be what is most commonly used, that typically won't be the case with the MADE relationship. Just as REV=Previous indicates that this page is thought of as “Previous” by the specified value, likewise REV=MADE indicates that the page is “Made” by the the specified value. (See LINK page discussing this.)

In XHTML, <LINK> tags should end with a space and a slash before the greater-than sign that ends the tag.

Link - Document relationship says, “While the value of REL and REV is case-insensitive, the Lynx browser renders the relationship exactly as given by the author. Authors should therefore be consistent in their case,” advice which is probably not necessary for technical reasons but rather stylish ones: Viewers would be able to see inconsistency.

The <LINK> element can be useful in the following ways:

HTML 4.0 list of link types.


Webmasters who make multiple web pages can probably have opportunity to use multiple of these tags.

This may cause pre-caching by some Mozilla products. The “Child” relationship may show up in Mozilla products as the word “Next”, but not perform the pre-caching. The “Next” relationship, though, is likely to be supported by more web browsers.
Previous, also widely supported is Prev, although in Opera Prev is overridden by Previous.
Up, or Parent
First, Begin
Also, some browsers support “End”, but “Last” overrides “End”. Note that End's opposite is not necessarily "Start": See other references to "Start" for more details. iCab renders “Last” as “Last page”.
Home. See also: Start, top. A link to the home page? (Similar to Start?) Note that a common HTML standard developed to also place a hyperlinked site logo in the upper-left corner of a page, often showing a site logo.
iCab also supports “Find”.
Top. Mozilla may also support “Origin”. Opera renders this as “Home” and this is overriden by either “Home” or “Start”. iCab renders this as “Start page”, just like it does for the “Start” relationship.

HTML 4.0 list of link types describes as “Refers to a document offering help (more information, links to other sources information, etc.)”

(Help is mentioned by Document Header.)

Specific page types
[#madenlgl]: Authorship and Legal

The most common method is MADE, followed by an E-Mail address. Some pages will specify MADE followed by a person's name. HTML REL, REV - HTML Code Tutorial demonstrates both using syntax of: <LINK REV=MADE TITLE=“Person's Name” HREF=“”> However, TITLE is used differently by another tutorial: page.

Note that this is the one relationship where REV is considered to be most commonly more correct than REL.

If you're interested in this, then the HTML character entity of &copy; (©) may be of some use.
Another page type which sounds like it would have legal text. Note that this attribute is not specified by HTML 4.0 list of link types, nor is any support noted by the Link Bars web site. Usage of the “Copyright” relation may be more widespread.
How does this compare to MADE?
Likely some more legal text?
Book-like references

The “Contents” relationship is probably going to be the most used relationship from this section.

Table of Contents
This is probably the most commonly used book-like feature that a large number of web sites clearly implement. The relationship most commonly supported is called “Contents”. Another commonly used one is ToC. Link Bars says that Contents overrides ToC in the web browser called Opera.
Valid relationships in HTML 4.0 list of link types include Chapter, Section, and Subsection.
An index. Similar in concept to a table of contents, in that it helps a person find some specific information. The main difference between an Index and a Table of Contents is that an Index is sorted by word, instead of sorted by the order that things appear (which causes books to typically have the content sorted by page numbers). Also, indexes tend to be more valuable when they have more content, while a “Table of Contents” may have more limited details, in an effort to keep the “Table of Contents” relatively brief.
A list of terms and definitions
Also, BiblioEntry
??? Perhaps similar in concept to the <BLOCKQUOTE CITE=""> ... </BLOCKQUOTE> standard HTML?
Editor, Publisher
??? (How does this compare to <A NAME>?)

“Alternate”, particularly when used with the “lang” attribute (per HTML 4.0 list of link types). So, for example, the tag might look something like: <LINK Alternate="about:blank" lang="de">

Link Bars web page also references a “Translation” relationship (instead of an “Alternate” relationship), but that doesn't seem to be widely supported. Therefore, the preferable method seems to be using “Alternate” instead of “Translation”.

Alternate, lang attribute (per HTML 4.0 list of link types). A value from HTML 4.0: Link type: Media Descriptors may be used.
Link Bars references hreflang
Other more common one(s)

(The “Help” tag type was previously mentioned here, but is discussed further in the “Navigation” section.)

Banner (discussed by Document Header), Meta, Navigator, Prefetch (caches), Script, Sibling
Newer technologies
CSS: <LINK REL="stylesheet" HREF="filename.css" type="text/css" />
Shortcut Icons

Having this on a page tells the web browser the location of a shortcut icon that the browser should use, and indicates that the browser should not try to look for /favicon.ico as the location of a shortcut icon. The most standards-compliant way to use this would be <LINK REL="Icon" TYPE=";image/; HREF="filename.ico">

(The TYPE field may not be needed. The value of came from Wikipedia's article on Favicon, citing IANA recognition. An alternative value of image/png may be supported by Firefox and other browsers.)

The sometimes-used format of <LINK REL="Shortcut Icon" HREF="filename.ico"> is in violation of standard specifications, which indicate that a space in a relationship field is meant to separate multiple relationships, although using that may actually work on comforming browsers that look for the “Icon” relationship (and would ignore the word “Shortcut”).


Many web pages have specified a “privacy policy”. This became common practice after the early days when the <LINK> tag standards were first becoming developed. There does not seem to be a known standard for the LINK tag specifying a page for a privacy policy, although many websites could make use of such a thing. (Actually, if a major web browser did decide to support a button or menu option to go to a site's “privacy” page, supporting other types of policies might also be sensible.)

Actually, the support for the privacy policy has been standardized by using a different standard, which is W3C's Platform for Privacy Preferences (P3P) Project. W3C P3P page noted that an update that that specification was published in a state called “provisionally final” because “there was insufficient support from current Browser implementers for the implementation of P3P 1.1.”

Perhaps “Disclaimer” is the pre-existing LINK tag type that would be most relevant for a privacy policy?