What's the difference between Angular property and attribute binding?
Tests whether you know Angular binds to DOM properties by default. [disabled] sets a DOM property; [attr.role] sets an HTML attribute. Use attribute binding when no DOM property exists, such as SVG attributes or role. Red flag: claiming they are equivalent.
What's really being asked
This question tests whether you understand Angular's template binding mechanics at the DOM level. Interviewers want to see that you know property bindings interact with the element's DOM object instance, while attribute bindings interact with the HTML markup attribute. It also checks if you can identify cases where a DOM property does not exist for a given HTML attribute, forcing you to use the attr prefix.
The full answer
First, explain that square bracket syntax without a prefix writes to a DOM property. For example, binding disabled on a native button element sets the disabled property on the HTMLButtonElement instance in the DOM. Second, explain that the attr prefix tells Angular to set the HTML attribute instead of the DOM property, such as writing attr role to set the role attribute on the underlying element. Third, state the rule of thumb from the documentation: use attribute binding when you need to set HTML attributes that do not have corresponding DOM properties. Fourth, mention that the same square bracket syntax works for component and directive inputs, but the distinction between property and attribute binding matters most for native HTML elements.
The mistakes people make
A major red flag is claiming that properties and attributes are always synchronized or identical. Another wrong answer is saying that value and attr value behave the same way in all scenarios. Some candidates incorrectly state that Angular always uses attributes under the hood, or that you should default to attr bindings for everything. Failing to provide a concrete example where attribute binding is required, such as SVG attributes or the role attribute, also weakens the answer.
What usually comes next
An interviewer might ask what happens when a property and attribute have the same name but different values, or how change detection interacts with each binding type. They might also ask you to name other scenarios where attribute binding is necessary beyond SVG and ARIA, or how binding to component inputs differs from binding to native DOM properties.
A concrete example
Suppose you have an unordered list element and you need to dynamically set its ARIA role based on component state. Because you are setting an HTML attribute that does not have a corresponding DOM property in the way the framework expects, you write ul with attr role binding equals listRole parentheses. In the component class, listRole is a signal or property that returns a string such as listbox. When the signal changes, Angular updates the role attribute in the actual HTML markup. If you tried to use plain square brackets role without the attr prefix, Angular would attempt to set a DOM property that does not exist for this purpose on the element instance, so the binding would not work as intended.
Interview question
In Angular, binding [disabled]="isDisabled" on a button sets the DOM property. Why must ARIA roles use [attr.role] instead of [role]?
- a.Property bindings are reserved for component @Input() decorators and native form controls
- b.Angular's change detection monitors attributes more efficiently than properties for string values
- c.HTML attributes automatically sanitize their values, whereas DOM properties do not
- d.The role HTML attribute has no corresponding DOM property on standard elements, so Angular must write to the markup directlyCorrect
Why? this is the answer
Angular writes to DOM properties by default, so attribute binding is required when no corresponding DOM property exists, such as with ARIA role or SVG attributes. Option B is tempting because it suggests a framework optimization, but the distinction is about the binding target, not change detection efficiency.
Just read this? Test yourself on what you have been reading.
Read the original → angular.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on angular — each one lists the topics its interview covers.
See open roles