The :visited pseudo-class in CSS applies styles to links (<a> elements) that the user has previously visited. This allows designers to visually differentiate between links that have been clicked and those that haven't.

Example: Using :visited

In this example, links that the user has not visited appear blue, while visited links appear purple.

Best Practices and Limitations

1
Use :visited to provide visual cues about link history, improving navigation experience.
2
Browsers restrict which CSS properties can be applied to :visited for privacy reasons (e.g., color changes are allowed, but background images are typically blocked).
3
Combine :visited with :hover and :active for consistent interactive feedback.
4
Test link styling across browsers, as some may handle visited links differently to prevent history leakage.

Difficulty: 5/10

Topics: CSS selectors, privacy restrictions, browser rendering

Scenario Questions

0-2 years experience

1
You need to style links that the user has already visited to appear purple. How would you write the CSS selector, and what are the limitations you need to be aware of?
2
If a user’s browser is set to block history sniffing, what will happen to the colors you apply with :visited?

2-5 years experience

1
We have a component that conditionally adds a class to links based on whether they’re internal or external. After deploying, the visited styling stopped working on some pages. Walk me through how you would debug this.
2
Explain why changing the background-image of a :visited link is ignored by browsers, and how you would achieve a visual indication of visited state without violating privacy restrictions.

5-8 years experience

1
Our site uses a CSS-in-JS library that generates class names at runtime. How would you ensure that :visited styles are applied consistently across server‑rendered and client‑only components, considering browser privacy rules?
2
Discuss the performance and security trade‑offs of using :visited to indicate read status in a large news platform with millions of users, and propose an alternative approach if needed.

8+ years experience

1
We are migrating a legacy monolith to a micro‑frontend architecture. Different teams own different style systems, and some still rely on :visited for user‑read tracking. How would you standardize link styling while avoiding cross‑team privacy regressions?
2
Consider a scenario where a third‑party widget injects its own stylesheet that overrides your :visited rules. What governance or tooling would you put in place to prevent unintended side effects at scale?

Follow-up Questions

❓Which CSS properties are allowed on :visited and why?
❓How would you verify that your :visited styling works across major browsers?
❓What security or privacy concerns arise from exposing visited state?