Source Code

<div class="wrap">
  <div class="claim-card">
    <div class="claim-head">
      <div>
        <h3>Claim #CLM-77291</h3>
        <p>Auto collision &middot; Filed Aug 12, 2026</p>
      </div>
      <span class="claim-amount">$3,420.00</span>
    </div>

    <div class="claim-stepper" id="claimStepper">
      <div class="claim-step done" data-step="0">
        <span class="claim-dot"></span>
        <span class="claim-step-label">Submitted</span>
      </div>
      <div class="claim-step done" data-step="1">
        <span class="claim-dot"></span>
        <span class="claim-step-label">Under review</span>
      </div>
      <div class="claim-step active" data-step="2">
        <span class="claim-dot"></span>
        <span class="claim-step-label">Approved</span>
      </div>
      <div class="claim-step" data-step="3">
        <span class="claim-dot"></span>
        <span class="claim-step-label">Paid</span>
      </div>
    </div>

    <button class="claim-toggle" id="claimToggle">View timeline <svg width="13" height="13" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2.5"><polyline points="6 9 12 15 18 9"/></svg></button>

    <div class="claim-timeline" id="claimTimeline">
      <div class="claim-event">
        <span class="claim-event-date">Aug 22</span>
        <p>Claim approved for $3,420.00 — payout scheduled.</p>
      </div>
      <div class="claim-event">
        <span class="claim-event-date">Aug 18</span>
        <p>Adjuster inspection completed, damages confirmed.</p>
      </div>
      <div class="claim-event">
        <span class="claim-event-date">Aug 14</span>
        <p>Assigned to adjuster Maria Chen for review.</p>
      </div>
      <div class="claim-event">
        <span class="claim-event-date">Aug 12</span>
        <p>Claim submitted with photos and police report.</p>
      </div>
    </div>
  </div>
</div>

Learn Coding Visually

Learn to code with interactive, live-preview playgrounds — HTML, CSS, JavaScript, React & more.

See all ->
HTML Playground42 lessons · Click-based · Live previewCSS PlaygroundLearn CSS with a live editorJavaScript Playground60 lessons · DOM · Async · CanvasReact PlaygroundLearn React with a live code editorGSAP PlaygroundLearn GSAP animation interactivelySVG Playground44 lessons · shapes · paths · animationSCSS Playground45 lessons · Sass modules · tokensTailwind PlaygroundLearn Tailwind CSS with a live editorBootstrap 5 Playground50 lessons · live preview

Insurance Claim Status Card — Free HTML CSS JS Snippet

Insurance Claim Status Card · Cards · Plain HTML, CSS & JS · Live preview

TagsSVGDashboard UI

What's included

Features

Connected four-step stepper where the connecting line between two steps only fills in once the earlier step is complete
Active step rendered with a distinct halo/glow ring, separate from the filled "done" state
Collapsible timeline using the same max-height transition technique as an accordion, defaulting to closed
Claim dollar amount kept visually prominent and separate from the status stepper
Live demo transition shows a step completing, the next step activating, and a new timeline event fading in
New timeline events animate their entrance via requestAnimationFrame rather than appearing instantly
Toggle button label and chevron direction both reflect the timeline's open/closed state
Compact card suited to an insurance customer portal or claims-tracking mobile app

About this UI Snippet

Insurance Claim Status Card — Connected Step Tracker & Collapsible Event Timeline

Screenshot of the Insurance Claim Status Card snippet rendered live

An insurance claim can sit open for weeks, and the person waiting on it usually just wants one question answered without calling anyone: where is my claim right now, and what happened before that. This card answers both — a connected four-step stepper shows the current stage at a glance, and a collapsible timeline underneath holds the full history for anyone who wants the detail without cluttering the default view.

A stepper whose connecting line encodes progress, not just the dots

Each .claim-step has a ::after pseudo-element line connecting it to the next step, and that line only turns indigo when the *current* step carries the .done class — so the filled-in portion of the connecting line always tracks exactly how many steps are complete, not just which dot is currently highlighted. The active step gets a distinct halo (box-shadow: 0 0 0 4px) around an otherwise-empty dot, visually distinguishing "in progress right now" from "already completed," a distinction a claimant genuinely cares about — approved-but-not-yet-paid is a meaningfully different state from paid.

The timeline as a collapsible companion, not the default view

#claimTimeline starts collapsed via max-height: 0; overflow: hidden, the same max-height transition technique used in the accordion FAQ pattern, expanding to max-height: 400px when .open is toggled. Defaulting to collapsed keeps the card's primary information (current stage, claim amount) uncluttered for someone who just wants a quick status check, while still making the full adjuster-by-adjuster history one click away for someone who wants to understand exactly what happened and when.

A live status change to demonstrate the pattern, not a real backend

The setTimeout block three seconds into the page's life simulates a claim genuinely advancing: it moves the .active class from the "Approved" step to "Paid," marks "Approved" as .done, and prepends a new timeline event describing the payout — all without any real backend push. This exists purely to demonstrate the visual mechanics (the stepper filling in, the connecting line recoloring, a new event fading into the timeline) that a real integration would trigger from a webhook or polling call; remove it and drive the same class changes from your claims-management API's actual status field instead.

A newly inserted timeline event fades in rather than appearing instantly

The dynamically created .claim-event element starts at opacity: 0 and is only animated to opacity: 1 inside a requestAnimationFrame callback after being inserted into the DOM — the extra frame delay is necessary because setting opacity and immediately transitioning it in the same synchronous block would have the browser coalesce both style writes before painting, skipping the transition entirely. This is the standard technique for animating a freshly-inserted element's entrance.

Claim amount kept visually separate from the status information

The dollar amount sits in the card header, styled in green and right-aligned, distinct from the stepper and timeline below it — a claimant's two top concerns (how much, and how far along) are answered in the first half-second of looking at the card, with supporting detail available but not demanding attention.

Build with AI

Build, Understand, Optimize, and Extend It With AI

Paste this snippet's HTML, CSS, and JS into an AI coding assistant like Claude and ask it to explain exactly why the connecting line between two stepper steps is tied to the earlier step's "done" class rather than the later step's "active" class, and what would look wrong if that logic were reversed. The same assistant can help optimize it — for instance asking whether the requestAnimationFrame-based fade-in for new timeline events would still work reliably if multiple events were inserted in rapid succession. It's also useful for extending the card: ask it to add a "claim denied" branch state with its own stepper styling, support an arbitrary number of steps driven from a data array instead of hardcoded HTML, or add estimated-completion-date text for the current step. Treat the code less like a finished artifact and more like a starting point for a conversation.

Prompt to recreate it

Copy this into your AI assistant of choice to build the effect from scratch, or as a jumping-off point for your own variant:

text
Build an "insurance claim status" card in plain HTML, CSS, and JavaScript — no framework, no library.

Requirements:
- Show a claim number, claim type, filed date, and dollar amount, plus a horizontal connected step tracker with at least four stages (for example Submitted, Under Review, Approved, Paid).
- Each step must render as a dot connected to the next step by a horizontal line; a step that is fully complete gets a filled dot and its connecting line to the next step recolored to indicate progress, while the current in-progress step gets a distinct hollow-dot-with-glow style different from both the completed and the not-yet-started styles.
- Include a collapsible "timeline" section below the stepper, closed by default, that expands via a max-height CSS transition (not a JavaScript height calculation) when a toggle button is clicked, revealing a dated list of past claim events; the toggle button's icon must rotate and its label text must change between an open and closed wording.
- Include a JavaScript-driven demonstration (using a timer, not real backend data) that, after a few seconds, advances the claim to its next stage: moves the "active" styling to the next step, marks the previous step "done" so its connecting line updates, and inserts a brand-new event at the top of the timeline that fades in from transparent rather than appearing instantly — explain in a comment why a fade-in on a freshly inserted DOM element needs an extra animation frame before its opacity transition will actually run.

Want to tighten it up first? Run this prompt through the AI Prompt Studio to score it across 8 quality dimensions, catch anti-patterns, and tune the wording for Claude, ChatGPT, or Gemini before you paste it in.

Step by step

How to Use

  1. 1
    Watch the demo advanceAfter about 3 seconds the claim automatically moves from "Approved" to "Paid," with the stepper and a new timeline event animating in to show the mechanics.
  2. 2
    Click "View timeline"Expands a collapsible history of claim events with dates, using the same max-height transition as an accordion.
  3. 3
    Replace claim detailsUpdate the claim number, type, filed date, and dollar amount in the HTML header.
  4. 4
    Set the real current stepGive the correct .claim-step elements the .done or .active class based on your claim's actual current stage instead of the hardcoded demo state.
  5. 5
    Wire step changes to your claims APIReplace the setTimeout demo block with real status-change handling — for example a webhook or polling result — that moves .active and .done classes and prepends a new timeline event.
  6. 6
    Export in your formatClick "HTML" for a standalone file, "JSX" for a React component, or "Tailwind" for a Tailwind CSS version.

Real-world uses

Common Use Cases

Insurance customer self-service portals
The core use case — let policyholders check claim status without calling an agent, reducing support call volume for routine status checks.
Auto, home, and health claim tracking apps
The same stepper and timeline pattern works for any multi-stage claim type by relabeling the four steps and timeline event copy.
Claims adjuster internal dashboards
Adjusters managing many open claims can use a denser version of the same stepper to see each claim's stage in a list or table view.
ALERT
Status-change email and SMS notification pages
Link a claim-status-change email directly to this card's live state so the recipient sees exactly what changed without hunting through a full portal.
Learn progress-encoding step trackers
A clean example of a stepper where the connecting line itself communicates progress rather than relying solely on dot color, useful for any multi-stage process tracker (onboarding, shipping, approval workflows).
Warranty and repair claim tracking
Product warranty claims and repair-shop order tracking follow the same submitted-review-approved-fulfilled shape as an insurance claim.

Got questions?

Frequently Asked Questions

Each .claim-step has a ::after pseudo-element line to the next step, and that line is only recolored to indigo via the CSS rule .claim-step.done:not(:last-child)::after — so the line only fills in when the step it belongs to has the .done class, keeping the visual progress line in sync with actually-completed steps rather than just the currently active one.

A .done step has a fully filled indigo dot. An .active step has an empty white dot with an indigo border plus a soft glow ring (box-shadow) around it — distinguishing "this step is finished" from "this step is currently in progress," which matters because a claim that is approved-but-not-yet-paid is meaningfully different from one that has been fully paid out.

The card's primary information — current stage and claim amount — is meant to be readable in the first glance. The full event-by-event history is useful detail but not something every viewer needs immediately, so it is tucked behind a toggle using the same max-height accordion transition technique, expanding to a generous max-height only when explicitly requested.

Setting an element's opacity to 0, inserting it into the DOM, and then immediately setting its transition and opacity to 1 in the same synchronous code block risks the browser batching both style changes together before ever painting the initial state, which would skip the fade entirely. Wrapping the transition-in step in requestAnimationFrame forces the browser to paint the initial opacity: 0 state first, guaranteeing the fade actually animates.

Replace the setTimeout demo block with your own event handling — for example a webhook payload or a polling response — that moves the .active class to the new current step, adds .done to any steps that are now complete, and calls the same insertBefore-plus-fade-in logic to prepend a new event to the timeline with real event copy and a real date.

Yes — add or remove .claim-step elements inside #claimStepper with sequential data-step values. The CSS uses flex: 1 on each step so any number of steps distributes evenly across the stepper's width, and the connecting-line and done/active styling applies per-step regardless of the total count.