[html] Should I make HTML Anchors with 'name' or 'id'?

When one wants to refer to some part of a webpage with the "http://example.com/#foo" method, should one use

<h1><a name="foo"/>Foo Title</h1>

or

<h1 id="foo">Foo Title</h1>

They both work, but are they equal, or do they have semantic differences?

This question is related to html hyperlink fragment-identifier

The answer is


The whole "named anchor" concept uses the name attribute, by definition. You should just stick to using the name, but the ID attribute might be handy for some javascript situations.

As in the comments, you could always use both to hedge your bets.


Heads up for JavaScript users: all IDs become global variables under window.

<h1 id="foo">Foo Title</h1>

Just created the JS global:

window.foo

The value of window.foo will be the HTMLElement for the h1.

Unless you can guarantee all values used in id attributes are safe, you may prefer sticking to name:

<h1 name="foo">Foo Title</h1>

The second sample assigns a unique ID to the element in question. This element can then be manipulated or accessed using DHTML.

The first one, on the other hand, sets a named location within the document, akin to a bookmark. Attached to an "anchor", it makes perfect sense.


I have to say if you are going to be linking to that area in the page... such as page.html#foo and Foo Title isn't a link you should be using:

<h1 id="foo">Foo Title</h1>

If you instead put an <a> reference around it your headline will be influenced by an <a> specific CSS within your site. It's just extra markup, and you shouldn't need it. I'd highly recommend placing an id on the headline, not only is it better formed, but it will allow you to either address that object in Javascript or CSS.


How about using name attribute for old browsers and id attribute to the new browsers. Both options will be used and fallback method will be implemented by default!!!


I have to say if you are going to be linking to that area in the page... such as page.html#foo and Foo Title isn't a link you should be using:

<h1 id="foo">Foo Title</h1>

If you instead put an <a> reference around it your headline will be influenced by an <a> specific CSS within your site. It's just extra markup, and you shouldn't need it. I'd highly recommend placing an id on the headline, not only is it better formed, but it will allow you to either address that object in Javascript or CSS.


The second sample assigns a unique ID to the element in question. This element can then be manipulated or accessed using DHTML.

The first one, on the other hand, sets a named location within the document, akin to a bookmark. Attached to an "anchor", it makes perfect sense.


<h1 id="foo">Foo Title</h1>

is what should be used. Don't use an anchor unless you want a link.


The second sample assigns a unique ID to the element in question. This element can then be manipulated or accessed using DHTML.

The first one, on the other hand, sets a named location within the document, akin to a bookmark. Attached to an "anchor", it makes perfect sense.


Heads up for JavaScript users: all IDs become global variables under window.

<h1 id="foo">Foo Title</h1>

Just created the JS global:

window.foo

The value of window.foo will be the HTMLElement for the h1.

Unless you can guarantee all values used in id attributes are safe, you may prefer sticking to name:

<h1 name="foo">Foo Title</h1>

ID method will not work on older browsers, anchor name method will be deprecated in newer HTML versions... I'd go with id.


There's no semantic difference; the trend in the standards is toward the use of id rather than name. However, there are differences that may lead one to prefer name in some cases. The HTML 4.01 specification offers the following hints:

Use id or name? Authors should consider the following issues when deciding whether to use id or name for an anchor name:

  • The id attribute can act as more than just an anchor name (e.g., style sheet selector, processing identifier, etc.).
  • Some older user agents don't support anchors created with the id attribute.
  • The name attribute allows richer anchor names (with entities).

The whole "named anchor" concept uses the name attribute, by definition. You should just stick to using the name, but the ID attribute might be handy for some javascript situations.

As in the comments, you could always use both to hedge your bets.


ID method will not work on older browsers, anchor name method will be deprecated in newer HTML versions... I'd go with id.


There's no semantic difference; the trend in the standards is toward the use of id rather than name. However, there are differences that may lead one to prefer name in some cases. The HTML 4.01 specification offers the following hints:

Use id or name? Authors should consider the following issues when deciding whether to use id or name for an anchor name:

  • The id attribute can act as more than just an anchor name (e.g., style sheet selector, processing identifier, etc.).
  • Some older user agents don't support anchors created with the id attribute.
  • The name attribute allows richer anchor names (with entities).

Wikipedia makes heavy use of this feature like this:

<a href="#History">[...]</a>
<span class="mw-headline" id="History">History</span>

And Wikipedia is working for everybody, so I would feel safe sticking with this form.

Also don't forget, you can use this not only with spans but with divs or even table cells, and then you have access to the :target pseudo-class on the element. Just watch out not to change the width, like with bold text, cause that moves content around, which is disturbing.

Named anchors - my vote is to avoid:

  • "Names and ids are in the same namespace..." - Two attributes with the same namespace is just crazy. Let's just say deprecated already.
  • "Anchors elements without href atribute" - Yet again, the nature of an element (hyperlink or not) is defined by having an atribute?! Double crazy. Common sense says to avoid it altogether.
  • If you ever style an anchor without a pseudo-class, the styling applies to each. In CSS3 you can get around this with attribute selectors (or same styling for each pseudoclass), but still it's a workaround. This usually doesn't come up because you choose colors per pseudo-class, and the underline being present by default it only makes sense to remove, which makes it the same as other text. But you ever decide to make your links bold, it'll cause trouble.
  • Netscape 4 might not support the id feature, but still an unknown attribute won't cause any trouble. That's what called compatibility for me.

The second sample assigns a unique ID to the element in question. This element can then be manipulated or accessed using DHTML.

The first one, on the other hand, sets a named location within the document, akin to a bookmark. Attached to an "anchor", it makes perfect sense.


In html 5, the id="" attribute defines a unique identifier for an element, which is also an anchor for a fragment link. In previous html standards, the name="" attribute of the <a> element defines an anchor for a fragment link. I recommend something like:
<a name="foo" id="foo"></a><h4>Foo Title</h4>
Because support for the id="" attribute is a bit spotty(even though the latest releases of all major browsers support it, the releases that don't aren't more than a few years old[And it's best not to break something if there isn't a good reason to]). It's compatible, & it doesn't style whatever's in the link'd element, for the closing </a> is still outside the element, but it's still valid in all current standards.

Be sure that the name="" and id="" attributes of the <a> element are the same.


Just an observation about the markup The markup form in prior versions of HTML provided an anchor point. The markup forms in HTML5 using the id attribute, while mostly equivalent, require an element to identify, almost all of which are normally expected to contain content.

An empty span or div could be used, for instance, but this usage looks and smells degenerate.

One thought is to use the wbr element for this purpose. The wbr has an empty content model and simply declares that a line break is possible; this is still a slightly gratuitous use of a markup tag, but much less so than gratuitous document divisions or empty text spans.


I have to say if you are going to be linking to that area in the page... such as page.html#foo and Foo Title isn't a link you should be using:

<h1 id="foo">Foo Title</h1>

If you instead put an <a> reference around it your headline will be influenced by an <a> specific CSS within your site. It's just extra markup, and you shouldn't need it. I'd highly recommend placing an id on the headline, not only is it better formed, but it will allow you to either address that object in Javascript or CSS.


I have a web page consisting of a number of vertically stacked div containers, identical in format and differing only in serial number. I wanted to hide the name anchor at the top of each div, so the most economical solution turned out to be including the anchor as an id within the opening div tag, i.e,

<div id="[serial number]" class="topic_wrapper">

There's no semantic difference; the trend in the standards is toward the use of id rather than name. However, there are differences that may lead one to prefer name in some cases. The HTML 4.01 specification offers the following hints:

Use id or name? Authors should consider the following issues when deciding whether to use id or name for an anchor name:

  • The id attribute can act as more than just an anchor name (e.g., style sheet selector, processing identifier, etc.).
  • Some older user agents don't support anchors created with the id attribute.
  • The name attribute allows richer anchor names (with entities).

You shouldn’t use <h1><a name="foo"/>Foo Title</h1> in any flavor of HTML served as text/html, because the XML empty element syntax isn’t supported in text/html. However, <h1><a name="foo">Foo Title</a></h1> is OK in HTML4. It is not valid in HTML5 as currently drafted.

<h1 id="foo">Foo Title</h1> is OK in both HTML4 and HTML5. This won’t work in Netscape 4, but you’ll probably use a dozen other features that don’t work in Netscape 4.


I have to say if you are going to be linking to that area in the page... such as page.html#foo and Foo Title isn't a link you should be using:

<h1 id="foo">Foo Title</h1>

If you instead put an <a> reference around it your headline will be influenced by an <a> specific CSS within your site. It's just extra markup, and you shouldn't need it. I'd highly recommend placing an id on the headline, not only is it better formed, but it will allow you to either address that object in Javascript or CSS.


In html 5, the id="" attribute defines a unique identifier for an element, which is also an anchor for a fragment link. In previous html standards, the name="" attribute of the <a> element defines an anchor for a fragment link. I recommend something like:
<a name="foo" id="foo"></a><h4>Foo Title</h4>
Because support for the id="" attribute is a bit spotty(even though the latest releases of all major browsers support it, the releases that don't aren't more than a few years old[And it's best not to break something if there isn't a good reason to]). It's compatible, & it doesn't style whatever's in the link'd element, for the closing </a> is still outside the element, but it's still valid in all current standards.

Be sure that the name="" and id="" attributes of the <a> element are the same.


There's no semantic difference; the trend in the standards is toward the use of id rather than name. However, there are differences that may lead one to prefer name in some cases. The HTML 4.01 specification offers the following hints:

Use id or name? Authors should consider the following issues when deciding whether to use id or name for an anchor name:

  • The id attribute can act as more than just an anchor name (e.g., style sheet selector, processing identifier, etc.).
  • Some older user agents don't support anchors created with the id attribute.
  • The name attribute allows richer anchor names (with entities).

<h1 id="foo">Foo Title</h1>

is what should be used. Don't use an anchor unless you want a link.


You shouldn’t use <h1><a name="foo"/>Foo Title</h1> in any flavor of HTML served as text/html, because the XML empty element syntax isn’t supported in text/html. However, <h1><a name="foo">Foo Title</a></h1> is OK in HTML4. It is not valid in HTML5 as currently drafted.

<h1 id="foo">Foo Title</h1> is OK in both HTML4 and HTML5. This won’t work in Netscape 4, but you’ll probably use a dozen other features that don’t work in Netscape 4.


ID method will not work on older browsers, anchor name method will be deprecated in newer HTML versions... I'd go with id.


You shouldn’t use <h1><a name="foo"/>Foo Title</h1> in any flavor of HTML served as text/html, because the XML empty element syntax isn’t supported in text/html. However, <h1><a name="foo">Foo Title</a></h1> is OK in HTML4. It is not valid in HTML5 as currently drafted.

<h1 id="foo">Foo Title</h1> is OK in both HTML4 and HTML5. This won’t work in Netscape 4, but you’ll probably use a dozen other features that don’t work in Netscape 4.


Wikipedia makes heavy use of this feature like this:

<a href="#History">[...]</a>
<span class="mw-headline" id="History">History</span>

And Wikipedia is working for everybody, so I would feel safe sticking with this form.

Also don't forget, you can use this not only with spans but with divs or even table cells, and then you have access to the :target pseudo-class on the element. Just watch out not to change the width, like with bold text, cause that moves content around, which is disturbing.

Named anchors - my vote is to avoid:

  • "Names and ids are in the same namespace..." - Two attributes with the same namespace is just crazy. Let's just say deprecated already.
  • "Anchors elements without href atribute" - Yet again, the nature of an element (hyperlink or not) is defined by having an atribute?! Double crazy. Common sense says to avoid it altogether.
  • If you ever style an anchor without a pseudo-class, the styling applies to each. In CSS3 you can get around this with attribute selectors (or same styling for each pseudoclass), but still it's a workaround. This usually doesn't come up because you choose colors per pseudo-class, and the underline being present by default it only makes sense to remove, which makes it the same as other text. But you ever decide to make your links bold, it'll cause trouble.
  • Netscape 4 might not support the id feature, but still an unknown attribute won't cause any trouble. That's what called compatibility for me.

The whole "named anchor" concept uses the name attribute, by definition. You should just stick to using the name, but the ID attribute might be handy for some javascript situations.

As in the comments, you could always use both to hedge your bets.


Just an observation about the markup The markup form in prior versions of HTML provided an anchor point. The markup forms in HTML5 using the id attribute, while mostly equivalent, require an element to identify, almost all of which are normally expected to contain content.

An empty span or div could be used, for instance, but this usage looks and smells degenerate.

One thought is to use the wbr element for this purpose. The wbr has an empty content model and simply declares that a line break is possible; this is still a slightly gratuitous use of a markup tag, but much less so than gratuitous document divisions or empty text spans.


You shouldn’t use <h1><a name="foo"/>Foo Title</h1> in any flavor of HTML served as text/html, because the XML empty element syntax isn’t supported in text/html. However, <h1><a name="foo">Foo Title</a></h1> is OK in HTML4. It is not valid in HTML5 as currently drafted.

<h1 id="foo">Foo Title</h1> is OK in both HTML4 and HTML5. This won’t work in Netscape 4, but you’ll probably use a dozen other features that don’t work in Netscape 4.


I have a web page consisting of a number of vertically stacked div containers, identical in format and differing only in serial number. I wanted to hide the name anchor at the top of each div, so the most economical solution turned out to be including the anchor as an id within the opening div tag, i.e,

<div id="[serial number]" class="topic_wrapper">

Examples related to html

Embed ruby within URL : Middleman Blog Please help me convert this script to a simple image slider Generating a list of pages (not posts) without the index file Why there is this "clear" class before footer? Is it possible to change the content HTML5 alert messages? Getting all files in directory with ajax DevTools failed to load SourceMap: Could not load content for chrome-extension How to set width of mat-table column in angular? How to open a link in new tab using angular? ERROR Error: Uncaught (in promise), Cannot match any routes. URL Segment Wrapping a react-router Link in an html button How to make a hyperlink in telegram without using bots? React onClick and preventDefault() link refresh/redirect? How to put a link on a button with bootstrap? How link to any local file with markdown syntax? link with target="_blank" does not open in new tab in Chrome How to create a link to another PHP page How to determine the current language of a wordpress page when using polylang? How to change link color (Bootstrap) How can I make a clickable link in an NSAttributedString?

Examples related to fragment-identifier

What's the shebang/hashbang (#!) in Facebook and new Twitter URLs for? Change hash without reload in jQuery Getting URL hash location, and using it in jQuery Modifying location.hash without page scrolling How to remove the hash from window.location (URL) with JavaScript without page refresh? On - window.location.hash - Change? Should I make HTML Anchors with 'name' or 'id'? How to get Url Hash (#) from server side How can you check for a #hash in a URL using JavaScript? Detecting Back Button/Hash Change in URL