Take the 2-minute tour ×

Expressions like Element.getAttribute("id") and Element.id return the same thing.

Which one should be used when we need attributes of an HTMLElement object?

Is there any cross browser issue with these methods like getAttribute() and setAttribute()?

Or any impact on performance between directly accessing object properties vs using these attribute methods?

share|improve this question
Similar question: Properties and Attributes in HTML –  sleske Oct 12 '13 at 18:14

5 Answers 5

up vote 24 down vote accepted

getAttribute retrieves the attribute of a DOM element, while el.id retrieves the property of this DOM element. They are not the same.

Most of the time, DOM properties are synchronized with attributes.

However, the synchronization does not guarantee the same value. A classic example is between el.href and el.getAttribute('href') for an anchor element.

For example:

<a href="/" id="hey"></a>
var a = document.getElementById('hey')
a.getAttribute('href') // "/"
a.href // Full URL except for IE that keeps '/'

This behavior happens because according to the W3C, the href attribute must be a well-formed link. Most browsers respect this standard (guess who doesn't?).

There is another case for the input's checked property. The DOM property returns true or false while the attribute returns the string "checked" or an empty string.

And then, there are some properties that are synchronized one-way only. The best example is the value property of an input element. Changing its value through the DOM property will not change the attribute (edit: check the first comment for more precision).

Because of these reasons, I'd suggest you keep using the DOM properties, and not the attributes, as their behavior differs between the browsers.

In reality, there are only two cases where you need to use the attributes:

  1. A custom HTML attribute, because it is not synced to a DOM property.
  2. To access a built-in HTML attribute, which is not synced from the property, and you are sure you need the attribute (for example, the original value of an input element).

If you want a more detailed explaination, I strongly suggest you read this page. It will take you a few minutes only, but you will be delighted by the information (which I summed up here).

share|improve this answer
+1 for generally good advice. The synchronization thing is slighty off though: the value property of an input does get its initial value from the attribute but is otherwise not tied to it at all. The value attribute is fully synchronized instead with the defaultValue property. Likewise checked and defaultChecked. Except in old IE (<=7 and compatibility modes later), which has broken getAttribute() and setAttribute(). –  Tim Down Apr 23 '12 at 12:29
Added your comment as "further explaination" :-) –  Florian Margaine Apr 23 '12 at 12:33
Thanks Tim and Florian :) –  P K Apr 23 '12 at 12:35
I think you've got the first example wrong. a.href returns full URL, a.getAttribute("href") returns the attribute exactly as defiend in HTML source. –  Salman A Apr 23 '12 at 12:52
Whoops, indeed :) –  Florian Margaine Apr 23 '12 at 12:54

According to this jsPerf test getAttribute is more slow than id property.


Oddly enough both statements perform very bad on IE8 (compared to other browsers).

share|improve this answer
Benchmark function overhead is the root of all evil... –  gdoron Apr 23 '12 at 12:19

Always use the properties unless you have a specific reason not to.

  • getAttribute() and setAttribute() are broken in older IE (and compatibility mode in later versions)
  • properties are more convenient (in particular, those corresponding to boolean attributes)

There are some exceptions:

  • accessing attributes of <form> elements
  • accessing custom attributes (although I'd discourage using custom attributes at all)

I've written about this subject a few times on SO:

share|improve this answer
Before IE 8, properties and attributes were treated identically. As you alluded to earlier, properties are the way to go. –  user1385191 Apr 23 '12 at 17:21
@MattMcDonald: Yes, that's the brokenness to which I was alluding. I didn't expand on it in this answer because I felt I'd done so enough in other answers I linked to :) –  Tim Down Apr 23 '12 at 17:32

getAttribute('attribute') normally returns the attribute value as a string, exactly as defined in the HTML source of the page.

However, element.attribute could return a normalized or calculated value of the attribute. Examples:

  • <a href="/foo"></a>
    • a.href will contain full URL
  • <input type="checkbox" checked>
    • input.checked will be true (boolean)
  • <input type="checkbox" checked="bleh">
    • input.checked will be true (boolean)
  • <img src='http://dummyimage.com/64x64/000/fff'>
    • img.width will be 0 (number) before the image is loaded
    • img.width will be 64 (number) when image (or first few bytes of it) is loaded
  • <img src='http://dummyimage.com/64x64/000/fff' width="50%">
    • img.width will be the calculated 50%
  • <img src='http://dummyimage.com/32x32/000/fff' style='width: 50px'>
    • img.width will be 50 (number)
  • <div style='background: lime;'></div>
    • div.style will be an object
share|improve this answer

.id saves the the function call overhead. (which is very small, but you asked. )

share|improve this answer
Hi gdoron, just for the sake of curiosity: I tried to find an 'official' explanation of this (beyond the empirical test, which is clear enough ;) ) but with no success. Do you have any link about it? –  mamoo Apr 23 '12 at 12:19

Your Answer


