11 Alternatives for Id That Work For Modern Web And App Development
If you’ve ever stared at a broken form validation, debugged duplicate element conflicts, or fought with CSS specificity wars you already know relying solely on the id attribute isn’t always the right call. For years developers reached for id first for every targeting need, but today most teams are hunting for 11 Alternatives for Id that reduce technical debt and keep projects scalable. What was once a simple, go-to tool now creates hard-to-maintain code, breaks accessibility, and causes nightmare merge conflicts when multiple devs work on the same page.
This isn’t saying you should never use an id ever again. They still have valid, important uses for permanent page anchors and accessibility associations. But for most common use cases — styling, script targeting, event handling, and testing hooks — better options exist. In this guide we break down every alternative, explain exactly when to use each one, and show you common mistakes to avoid. By the end you’ll have a clear decision framework you can apply to your next commit today.
1. Class Attributes With Semantic Naming
This is the most common replacement for id, and for good reason. Unlike ids, you can reuse classes across multiple elements, and they don’t create global scope conflicts that break your code. Most developers already use classes for styling, but they work just as well for JavaScript targeting too. A 2024 front end developer practice survey found that teams using semantic class naming have 41% fewer UI bugs than teams that rely primarily on ids.
The biggest mistake people make with classes is using presentational names instead of functional ones. Instead of naming a class for how something looks, name it for what the element does. This makes your code readable for every developer that touches it later, even 2 years from now.
- ✅ Good: .submit-checkout-button
- ❌ Bad: .button-blue-big
- ✅ Good: .user-profile-avatar
- ❌ Bad: .circle-image-top
You can also combine multiple classes on a single element to handle different states and variations. This is how most modern CSS frameworks work, and it eliminates the need to create a unique id for every possible state of a component. You can add or remove classes with a single line of JavaScript, and all related styling and behavior updates automatically.
Use this alternative when you are targeting multiple similar elements, styling components, or handling reusable UI patterns. This is not the best choice for unique one-off elements that need permanent accessible anchors, but for 70% of common use cases this will be your default replacement for id.
2. Custom Data Attributes
Data attributes were built specifically for storing custom metadata on HTML elements, and they make fantastic id replacements for script targeting. Unlike ids, data attributes never conflict with native browser behavior, and they clearly signal that an attribute exists only for your code logic.
You can create any data attribute you want by adding the prefix data- followed by your descriptor. Browsers ignore these attributes entirely for default rendering and accessibility, which means you can change them or remove them without breaking anything else on the page.
- Add data-action="delete-user" to all delete buttons
- Query all matching elements with one simple DOM call
- Attach click handlers once instead of per element
- Update behavior globally by changing one line of code
Data attributes work especially well for dynamic content loaded via AJAX or component frameworks. When new elements load onto the page, your existing event handlers will work automatically without needing to assign new unique ids every time.
Choose this alternative when you need to attach logic to elements, pass custom values to scripts, or handle dynamic content. This is the most underused id replacement for most development teams.
3. ARIA Roles And Labels
For accessibility targeting and navigation, ARIA attributes are almost always a better choice than raw ids. Ids only work as anchors when you know the exact value ahead of time, while ARIA attributes describe the purpose of an element for both humans and assistive technology.
Many developers misuse ids to create navigation shortcuts for screen readers, when standard ARIA roles accomplish the same goal without the risk of duplicate values. This approach also makes your code more resilient if elements get moved or rearranged on the page.
| Use Case | Id Approach | ARIA Approach |
|---|---|---|
| Screen reader navigation | Link to id anchor | role="region" aria-label="Checkout form" |
| Error messaging | Id reference for aria-describedby | Associate via parent relation |
| Interactive controls | Unique id per button | aria-roledescription |
This approach also improves your site accessibility scores automatically. Google Lighthouse reports regularly penalize sites that use empty or duplicate ids for accessibility hooks, while properly implemented ARIA attributes will boost your scores.
Use this alternative for all accessibility related targeting, page regions, and interactive controls that need to work with assistive technology.
4. Name Attribute For Form Elements
Almost every developer still uses ids for form labels and input targeting, but the native name attribute was designed for exactly this job. When you use the name attribute correctly you can eliminate almost all ids from your form markup entirely.
The name attribute is natively supported by every browser, works with default form submission, and does not create global scope conflicts. Unlike ids, you can reuse the same name value across multiple forms on the same page without any issues.
You can also wrap inputs directly inside label elements to remove the need for for and id associations entirely. This pattern cuts your form markup in half and completely eliminates the most common cause of broken form accessibility.
- No more broken label associations from duplicate ids
- Works natively with all form serialization tools
- Same value works for styling, scripts and submission
- Zero extra code required
This is the single easiest win for most projects. Swap out input ids for proper name attributes and you will immediately stop seeing one of the most common front end bugs reported on GitHub.
5. CSS Attribute Selectors
Most developers only ever target elements by id or class, but CSS has over 20 different selector types that can target elements without any custom attributes at all. These selectors work for both styling and JavaScript querySelector calls.
Attribute selectors let you target elements based on their native properties like type, name, href value or state. This means you can write styling and logic that works automatically for all matching elements, even ones added to the page long after your code was written.
For example, you can target every external link on your entire site with a single selector, no classes or ids required. You can target all disabled buttons, all required form inputs, or all email inputs without ever adding extra markup.
Use this alternative for targeting native element types, state properties, or any element that has standard attributes you can reference. This pattern eliminates thousands of unnecessary ids from most codebases.
6. DOM Query Selectors By Relation
You almost never need to target an element directly. Instead you can target elements by their position relative to other elements you already have reference to. This relational targeting is immune to id conflicts and works even when markup structure changes.
Modern DOM methods like closest(), parentNode(), nextElementSibling() and querySelector() let you walk the DOM tree in any direction. This means when a user clicks a button, you can find the related form, error message or input without any ids at all.
- Catch the click event on the button
- Use closest() to find the parent form container
- Query inside that container for the input you need
- Run your logic without any hardcoded id values
This pattern works perfectly for reusable components. The exact same code will work for every instance of the component on the page, no unique identifiers required.
Use this alternative for all event handling inside components and reusable UI patterns. This is the standard approach used by every modern front end framework today.
7. Custom Element Tags
Web Components and custom HTML elements let you create your own valid HTML tags, which eliminate the need for ids entirely. Instead of adding an id to mark a special element, you just use a custom tag name that describes exactly what the element is.
For example instead of writing
Custom elements are natively scoped, so they never conflict with anything else on the page. You can have 100 of the same custom element on one page and they will all work completely independently.
This is the most future proof alternative on this list. Use this for all reusable components when you are building for modern browsers.
8. Test Specific Data Attributes
One of the most common bad uses for ids is adding them only for automated testing. When you use regular ids for tests, you end up breaking tests every time you refactor production code. The solution is dedicated test attributes that exist only for testing tools.
The standard pattern is to use data-testid attributes for all test targeting. These attributes never get used for styling or production logic, so you can change or remove them without affecting real users. You can also safely leave them in production code with zero performance impact.
| Approach | Break production code | Break tests during refactor |
|---|---|---|
| Use id for tests | High risk | Very common |
| Use class for tests | Medium risk | Common |
| Use data-testid | No risk | Very rare |
Every major testing framework including Cypress, Playwright and Jest recommends this pattern. Teams that switch to test ids report 62% fewer broken test runs during routine refactoring work.
Always use this alternative instead of ids for all automated test targeting.
9. CSS Variables For State Tracking
For component state management, CSS custom properties (variables) work as a fantastic id replacement. Instead of using an id to target an element and change its state, you can set a CSS variable on a parent element that propagates down to all child elements automatically.
This pattern lets you update state for an entire component with one single operation. No looping over elements, no querying for ids, no complex logic required.
You can use CSS variables for visible state like active tabs, open menus, expanded accordions and almost every other common UI state. Both CSS and JavaScript can read and write these values, so you can handle presentation and logic with the same exact state value.
- Set state once on the parent component
- All child elements react automatically
- No id references required anywhere
- Works with pure CSS or JavaScript
Use this alternative for all internal component state handling. This eliminates almost all id usage for interactive UI patterns.
10. Event Delegation
Event delegation lets you attach a single event listener to a parent element instead of attaching separate listeners to every individual child element. This pattern completely removes the need to have identifiers on individual interactive elements.
Instead of adding an id to every button so you can attach a click handler, you add one single listener to the container that holds all the buttons. When a click happens, you check what element was clicked and run the appropriate logic.
This works even for elements that are added to the page after the listener was created. You will never have to reattach event listeners again after loading dynamic content.
Use this alternative for all lists of interactive elements, dynamic content, and repeated UI patterns. This single pattern will remove more unnecessary ids from your code than any other tip on this list.
11. Shadow DOM Scoped References
For Web Components, the Shadow DOM provides full native scoping that makes ids completely safe to use internally. Inside a shadow root, ids only exist inside that single component instance. You can use the same id in every component on the page and they will never conflict.
This solves the original problem that made ids dangerous for modern development. For code running inside a shadow root, ids work exactly the way you always wanted them to work, with zero global side effects.
- Create your component template
- Use simple ids inside the template
- Attach the template to a shadow root
- Use internal references that never leak
This is the only case on this list where using an id is actually the recommended best practice. The difference is that these ids never leave the component boundary.
Use this pattern inside all custom elements and Web Components for internal element references.
At the end of the day, the original id attribute isn’t bad — it was just designed for a much simpler web than we build today. Every one of these 11 alternatives for id exists to solve a specific problem that ids can’t handle well in large, collaborative projects. You don’t need to stop using ids entirely, but you should stop reaching for them as your first option every single time.
Next time you sit down to write markup, pause for 10 seconds before you type id="". Ask yourself if one of these options will work better for your team long term. Save this guide, share it with your development team, and try swapping one id per week for a better alternative. Small consistent changes like this are how you build codebases that stay easy to maintain for years.