HTML/CSS class and ID selectors: everything you need to know

Updated June 2026

The first time I helped a junior developer debug a stylesheet, the problem was two duplicate IDs fighting each other on the same page. The CSS looked fine. The HTML looked fine. But nothing rendered the way they expected. That moment captures why understanding css class vs id actually matters beyond textbook definitions.

Both class and id are HTML attributes. Both can be targeted by CSS selectors. That makes them look interchangeable when you are starting out. They are not interchangeable in good production code.

The core distinction is straightforward. Use a class for styles or behaviors you want to reuse across multiple elements. Use an id for one unique element on a page.

Getting this right affects more than just styling. It determines how clean your HTML structure is, how easy your CSS is to maintain, how CSS specificity resolves conflicts, how JavaScript targets elements, and how jump links in HTML work.

HTML and CSS interplay

HTML defines the structure of a page. CSS applies presentation to that structure. They work together, but they have distinct roles.

class and id are HTML attributes first. You write them directly on elements in your markup. CSS then references those attributes as selectors to apply styles to the right elements.

HTML elements can include class and id attributes, and CSS can target those attributes to apply styles. The class attribute is selected with a dot (.classname), and the id attribute is selected with a hash (#idname). CSS selectors are the mechanism that connects your stylesheet rules to specific parts of the page.

The attributes live in HTML. The styling rules live in CSS. Keeping that relationship clear helps you reason about both layers as your projects grow.

ID vs. class: what you need to know

A class labels one or more elements that share the same styling or behavior. An id identifies one specific, unique element on the page.

In CSS, the syntax reflects this difference:

• A class selector starts with a dot: .card
• An ID selector starts with a hash: #header

Here is how the css class vs id distinction breaks down in practice:

IDs are unique:

• Each id value should appear only once per page
• An element should have only one id
• IDs use the # symbol in CSS
• IDs can serve as targets for jump links in HTML
• Duplicate IDs on the same page are invalid and cause unpredictable behavior

Classes are reusable:

• The same class can be applied to many elements across a page
• A single element can carry multiple classes
• Classes use the . symbol in CSS
• Classes are the better default choice for most styling work

The HTML class vs id choice shapes how your CSS scales. When you reach for a class selector, you are building something reusable. When you reach for an ID selector, you are pointing at one exact thing. Most of the time, reusable is what you want.

CSS class vs id at a glance

This table summarizes the key differences between CSS class and ID selectors in one place.

Feature	Class	ID	Why it matters
CSS syntax	.card	#header	Helps you write selectors correctly
Reuse	Can be used on many elements	Should be used once per page	Affects scalability
Multiple values on one element	Yes	No practical equivalent	Classes are more flexible
Specificity	Lower	Higher	IDs are harder to override
JavaScript targeting	Good for groups	Good for one exact element	Shapes DOM access
Jump links in HTML	No	Yes	IDs can be fragment targets
Best default use	Reusable styling	Unique references	Improves maintainability

The takeaway: classes are flexible and reusable, which is what most styling needs. IDs are narrower and more specific, which is what unique references need.

When to use a class selector

The class selector is the right default for most styling work. I recommend reaching for a class first unless you have a specific reason to use an ID.

Classes work best when you need to style:

• Buttons
• Cards
• Alerts and notifications
• Repeated headings or labels
• Navigation items
• Shared layout patterns

Classes scale because they are reusable across many elements and easy to combine. Once you define a set of styles for a class name, you can apply it as many times as you need. Use an intuitive and logical naming convention so your class names describe what an element does, not just what it looks like.

One element can also carry multiple classes. This is one of the most practical features of the class selector. You can layer small, focused classes to build up the styling you need without duplicating CSS rules.

<button class="button primary">Save</button>
<button class="button secondary">Cancel</button>

.button { padding: 10px 16px; border: none; cursor: pointer; }
.primary { background: blue; color: white; }
.secondary { background: gray; color: white; }

Both buttons share the base .button styles. Each gets its own color treatment through a second class. This pattern keeps your CSS lean and your HTML readable. It is also much easier to maintain than writing separate ID-based rules for every button on the page.

When to use an ID selector

An ID selector should be reserved for one unique element on a page. Good use cases include:

• A page header (#site-header)
• A main content section (#main-content)
• A jump-link target
• A single element that JavaScript needs to reference directly

IDs are not the best default for styling. Their higher specificity makes them harder to override, and they cannot be reused. If you find yourself applying the same ID-based styles to multiple elements, that is a sign you should be using a class instead.

An element should only have one id. Duplicate IDs on the same page create invalid HTML, confusing CSS behavior, and unreliable JavaScript targeting. Browsers may still render the page, but the results are unpredictable and difficult to debug.

Think of IDs as labels for specific landmarks on your page. A page has one header, one footer, one main content area. Those are reasonable candidates for IDs. A set of product cards, blog post previews, or navigation links are not. Those are groups, and groups call for classes.

Why specificity matters

CSS specificity is the set of rules the browser uses to decide which style wins when more than one selector matches the same element.

ID selectors have higher specificity than class selectors. That means an ID-based rule will override a class-based rule on the same element, even if the class rule appears later in your stylesheet.

.note { color: blue; }
#warning { color: red; }

<p id="warning" class="note">This text will be red.</p>

The text renders red because #warning outranks .note in the specificity hierarchy. It does not matter that .note is a perfectly valid selector. The ID wins.

This is where the css class vs id decision has real consequences for maintainability. When your stylesheets grow, ID-based styles become hard to override without escalating to !important declarations. And once you start sprinkling !important through your CSS, you create a new layer of conflicts that is even harder to untangle.

Using IDs for styling often creates more problems than it solves. Classes keep specificity low and predictable. That makes your stylesheets easier to extend, easier to debug, and easier for other developers to work with.

How classes and IDs work in HTML, CSS, and JavaScript

The class vs id distinction matters beyond CSS. These attributes play different roles across three layers of front-end development.

• HTML stores the class and id attributes on elements
• CSS uses those attributes as selectors to apply styles
• JavaScript uses them to find and manipulate elements in the DOM

The DOM (Document Object Model) is the browser’s representation of your HTML as a tree of objects that JavaScript can interact with.

Context	Class	ID
HTML	class="card"	id="main-header"
CSS	.card {}	#main-header {}
JavaScript	getElementsByClassName("card")	getElementById("main-header")
Typical use	Shared styling or grouped behavior	One exact element

JavaScript’s getElementById() returns a single element. getElementsByClassName() returns a collection. That difference mirrors the core distinction: IDs point to one thing, classes point to groups.

Duplicate IDs break the assumption that getElementById() returns one unique result. If your HTML has two elements with the same id, the browser will return one of them. Which one depends on the browser. That is not a situation you want in production code.

Using IDs for jump links in HTML

One of the strongest non-styling uses of IDs is in-page navigation. Jump links in HTML let users click a link and scroll directly to a specific section of the page.

The pattern is simple. You place an id on the target element and create a link with an href that points to that id using a # prefix (called a fragment identifier).

<a href="#contact">Jump to contact section</a>

<h2 id="contact">Contact</h2>
<p>This is the contact section.</p>

When a user clicks the link, the browser scrolls to the element with id="contact". No JavaScript required.

This pattern is common in:

• Tables of contents
• Long tutorials or documentation
• FAQ pages
• Section navigation within a single page

The id goes directly on the target element. Older HTML patterns used <a name="sectionname"> as the anchor target, but that approach is outdated. Placing the id on the heading or section element itself is the modern, cleaner method.

Common mistakes to avoid

These are the mistakes I see most often when developers are learning to work with CSS class and ID selectors.

• Using the same ID more than once on a page. IDs must be unique. Duplicates create invalid HTML and unreliable behavior in both CSS and JavaScript.
• Using IDs for most styling instead of classes. IDs have higher specificity, which makes styles harder to override. Classes are almost always the better choice for styling.
• Forgetting the selector syntax. Classes use a dot (.classname). IDs use a hash (#idname). Mixing these up means your styles silently fail to apply.
• Assuming classes and IDs are interchangeable. They serve different purposes. Treating them as identical leads to brittle, hard-to-maintain code.
• Using vague names like box1 or div2. Names should describe what an element does or what it contains. Vague names make code harder to read and harder to maintain six months later.
• Creating specificity conflicts that are hard to undo. Mixing IDs and classes for styling without a clear pattern leads to escalating overrides and !important chains.

Good naming and consistent selector choice are not cosmetic preferences. They directly affect how maintainable your stylesheets are as a project grows.

Best practices for naming and structure

Descriptive names make your HTML and CSS easier to read, easier to search, and easier for other developers to understand.

Prefer names that describe function or content:

• .product-card instead of .box1
• .error-message instead of .red-text
• #site-header instead of #top

Avoid names that only describe appearance when possible. .big-blue-box tells you what it looks like today, but it stops being accurate the moment the design changes. .feature-highlight describes what the element does, which stays true regardless of styling updates.

Use classes for reusable UI patterns. Use IDs only for truly unique references like page landmarks, jump-link targets, or specific JavaScript hooks. Do not use IDs just to “win” a CSS specificity conflict. That is a workaround, not a strategy.

Consistency matters across a project. Pick a naming convention and stick with it. Whether you use simple descriptive names or a more structured approach, the goal is the same: anyone reading the code should be able to understand what each selector targets without hunting through the rest of the codebase.

Quick rule: class or ID?

When you are not sure which to use, this checklist covers most real-world situations.

• Use a class if multiple elements share the same style or behavior.
• Use a class if one element needs multiple reusable labels.
• Use an id if the element must be unique on the page.
• Use an id if you need a jump-link target.
• Use an id if JavaScript must reference one exact element.
• If you are styling a reusable UI pattern, choose a class first.

The css class vs id decision usually comes down to one question: will I ever need this on more than one element? If yes, use a class. If no, an ID might be appropriate, but a class still works.

My direct recommendation: default to classes. Reach for an ID only when you have a clear, specific reason.

The difference comes down to reuse vs. uniqueness

Classes are reusable. IDs are unique. That is the core distinction behind every decision about HTML/CSS class and ID selectors.

In practice, use classes for most styling. They keep specificity low, scale across elements, and are easier to maintain. Use IDs for unique references: page landmarks, jump links, and specific JavaScript targets.

Getting this right early saves real debugging time later. It also makes your front-end code easier for teammates to read, extend, and refactor. Clean selector habits are one of the simplest ways to write better, more maintainable web development code from the start.

Keep building your front-end skills

If you want to keep building your HTML, CSS, and programming fundamentals with hands-on projects, consider joining our specialized courses. You will move from basic syntax to practical front-end skills you can demonstrate in real work.

Start Learning