React Easy technical 0 views 1 min read

Why React uses `className` over `class` attribute?

Peer-reviewed by HireXTech Technical Panel Updated for 2025/2026 hiring Editorial standards
Practise this track
Interviewer Expectations for this Question
01
Core Competency

Assesses fundamental understanding of React conventions, runtime behavior, and memory/performance considerations.

02
Evaluation Criteria

Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.

Comprehensive Model Answer Verified Solution

React uses className instead of class because of a JavaScript naming conflict with the class keyword.

  1. class is a reserved keyword in JavaScript

In JavaScript, class is used to define ES6 classes:

        class Person {
          constructor(name) {
            this.name = name;
          }
        }
        

If you try to use class as a variable or property name, it will throw a syntax error. Since JSX is just JavaScript with XML-like syntax, using class directly in JSX would break the parser.

  1. JSX Is JavaScript

When you write JSX like this:

        <div class="btn">Click</div>
        

It will be compiled to:

        React.createElement('div', { class: 'btn' }, 'Click');
        

But class is invalid in this object literal context (since it clashes with the JS keyword), hence React instead uses className.

        <div className="btn">Click</div>
        

which compiles to:

        React.createElement('div', { className: 'btn' }, 'Click');
        

React then translates className to class in the final HTML DOM.

  1. Aligns with DOM APIs

In vanilla JavaScript, you interact with element classes using:

        element.className = 'my-class';
        

React follows this convention, staying consistent with the DOM API's property name rather than HTML’s attribute.

Candidate Response Strategy & Interview Tips

  1. Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
  2. Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
  3. Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
  4. Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.
Related Topics & Skills
Spotted an error or have an alternative solution?