use UI

Breadcrumb

Also called breadcrumbs, breadcrumb trail, path navigation

A trail of links showing the current page's ancestors in the site hierarchy, ending with the page itself.

Example

The trail is an <ol>, so the number of levels is announced without writing it out. The last item carries aria-current="page" and is not a link — it goes nowhere. Separators are aria-hidden: nobody needs to hear “chevron” four times on the way to the page name. This one is labelled Breadcrumb example rather than Breadcrumb, because the page you are reading already has a real breadcrumb above — and two navigations sharing a name cannot be told apart.

When to use it

  • The site is deep enough that “one level up” is a question worth answering — docs, catalogues, file browsers.
  • People arrive from search, straight into level four, with no idea what sits above them.
  • Sibling and parent pages are worth reaching, and a breadcrumb makes them one click away.
  • The hierarchy is real and stable. A breadcrumb is only honest if the parent genuinely contains the child.

When not to

  • The site is flat. Two levels of hierarchy do not need a trail; a single back link is clearer.
  • You want to show the user's path through the site. That is history, and the back button already owns it.
  • The page has no single parent — a product in five categories has no honest trail to draw.
  • It is the only navigation on the page. A breadcrumb supplements orientation; it does not replace a nav.

Trade-offs

  • Answers “where am I” for people who arrived from search rather than the front door.
  • Makes the whole ancestor chain reachable in one click each.
  • Costs almost nothing in vertical space, unlike most navigation.
  • Search engines read it, and it shapes how the result is displayed.
  • Useless on a flat site, where it is decoration that implies depth that is not there.
  • Long paths overflow on mobile and need truncating, which costs some of the orientation it was there to give.
  • Tempting to fill with the user's journey instead of the hierarchy, which quietly makes it wrong.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard
  • Every ancestor is a link, so Tab reaches them and they open in a new tab like any link.
  • The current page is not a link — it goes nowhere, and making it focusable adds a stop that does nothing.
  • If long paths collapse behind a “…” control, that control is a real button, not a decorative ellipsis.
Roles and state
  • Wrap it in `<nav aria-label="Breadcrumb">` — a page has several navigations and they need telling apart.
  • Use an ordered list: the sequence carries meaning, and a screen reader announces how many levels there are.
  • Mark the last item with `aria-current="page"`.
  • Separators belong to the styling, not the content. Draw them in CSS, or mark them `aria-hidden` — nobody needs to hear “slash” four times.
Focus
Nothing special: these are ordinary links and focus should behave ordinarily. If a collapsed trail expands, focus stays on the control that expanded it, and the newly revealed links follow in tab order.

In the wild

  • MDN — Deep reference pages reached from search — the trail is often the only clue about what section you landed in.
  • Amazon — Category trail above the product, which is also how most people move sideways into similar items.

Compared with

Side-by-side breakdowns of patterns that solve a similar problem.