A timeline is a list that has agreed to be read in order. That agreement is the whole value, and it is also the constraint: the moment the reader wants to jump to one entry, compare two, or search for a date, the shape stops helping and starts costing.
74 public components on 21st carry the timeline tag. They divide by what the sequence is for, and the split matters more than the styling, because three of these are the same component with a different label.
The vertical rail
A line down the page, entries alternating or aligned to one side. It is what most people mean by the word.
Timeline by Manu Arora is the version worth reading first: a sticky header with a beam that follows the scroll, so the reader always knows where in the sequence they are. That sticky-plus-progress combination is what separates a timeline from a list with dots.
Modern Timeline by Caio Bonato, Timeline by preetsuthar17 and Timeline by nyxbui are the plainer takes. Timeline Rail by nayan_radadiya6 is the minimal one.
The process
The same shape doing a different job: not history, but steps. Process Timeline by youcefbnm and Premium Process Timeline by Dhileep Kumar GM are built for "how it works" sections.
The distinction is worth keeping. A history timeline has dates and is complete. A process timeline has states - done, current, upcoming - and the current one has to be visually obvious, because that is the only thing the reader is looking for.
The changelog
ReleaseTimeLine by Ruixen UI is the version tuned for releases: version numbers, dates, grouped changes.
Worth saying plainly, because it is the most common mistake in this category: a changelog is content, not a component. Its value is in having real entries with real dates, and no amount of animation compensates for three entries from last spring.
The showpiece
Radial Orbital Timeline by Jatin Yadav is the most-bookmarked component in this family and the least like a timeline: nodes arranged in a circle around a centre, each carrying a title, a status and a level. 3D Interactive Timeline by the same instinct puts the sequence in perspective.
These are hero pieces. They are excellent at "this is a system with parts" and poor at "here is what happened in order", because a circle has no beginning and depth hides the far side. Choose one when the sequence is really a set.
The markup, which decides whether it is readable
A timeline is a list. Not a stack of divs with borders that look like a line.
An ordered list tells a screen reader how many entries there are and which one is being read, which is exactly the information a visual reader gets from the rail. The <time> element with a machine-readable datetime is what lets anything else - a crawler, an answer engine, a reader mode - understand that the string is a date. Both cost nothing and both are usually missing.
Three more that matter in production:
The line is decoration. Draw it with a pseudo-element or a border on the list, never as its own element in the DOM, or a screen reader announces something for every entry.
Long timelines need collapsing, not scrolling. Past twenty entries, group by year with the current year open. A page of two hundred dated entries is a page nobody reaches the bottom of.
Loading order is not display order. If entries arrive paginated, the newest-first API and the oldest-first display fight each other. Decide the display order once, sort on the client, and do not let the API's convenience decide how history reads.
Where else to look
The honest list of alternatives, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
An <ol> and CSS | Genuinely most timelines: a border, a pseudo-element, done | You write the sticky progress yourself |
| shadcn/ui | Card, Badge and Separator as the entry's parts | No timeline component at all |
| Recharts / visx | When the sequence is really data over time, not a story | A chart, not a narrative |
| 21st | Sticky-beam rails, process steps and the orbital showpieces | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a timeline, get the previews inline, and let the agent write the file.
Frequently asked
- What markup should a timeline use?
- An ordered list, with a time element carrying a machine-readable datetime inside each item. The list tells a screen reader how many entries there are and which one is being read, which is the information a sighted reader gets from the rail. Draw the line itself with a pseudo-element so it is never announced as content.
- What is the difference between a timeline and a process component?
- A history timeline has dates and is complete. A process timeline has states, done, current and upcoming, and the current step has to be visually obvious because it is the only thing the reader is looking for. They share a shape and almost nothing else, which is why the same component often fits one and fails the other.
- How do you handle a timeline with hundreds of entries?
- Group and collapse rather than scroll. Past roughly twenty entries, group by year with the current year expanded. Also decide the display order once and sort on the client: a newest-first API feeding an oldest-first design is the usual reason a timeline reads backwards on page two.
- When should a timeline be a chart instead?
- When the sequence is really data over time rather than a story. If the reader's question is about trend, magnitude or comparison, a chart answers it and a narrative rail does not. Keep the timeline for events that each need a sentence.