The Best JavaScript Product Tour Libraries in 2026: Open Source Options That Actually Work

Building your own product tours with a JavaScript library is easier than ever—especially now with AI-assisted development. You can spin up a functional tour with Driver.js or Intro.js in an afternoon, ship it with your code, and iterate fast. That's genuine value.

But here's what we know from talking to product teams: every company that starts with a JavaScript library eventually hits a tipping point where it stops being the right choice.

That tipping point arrives differently for different teams, but it's usually triggered by one of four problems: governance (who owns the tours, how do you version control them, who can make changes?), look and feel (you're constrained by the library's styling and animation capabilities), timing (coordinating tours with product releases and targeting specific user segments becomes a logistics nightmare), and the analytics disconnect (you can track events manually, but your analytics team sees a gap between what your tour library reports and what your real product analytics tool shows).

The product tour library landscape has shifted significantly since 2022. Some libraries that were promising five years ago are now essentially abandoned—Hopscotch was deprecated by LinkedIn, Trip.js barely gets touched, and Bootstrap Tour has fallen out of mainstream use. Meanwhile, a fresh crop of libraries has emerged, often with stronger TypeScript support, zero dependencies, and better accessibility out of the box.

This matters because choosing the right library now saves you months of technical debt later—but also because knowing when to graduate to a dedicated tool is equally important. We've researched the current state of open-source JavaScript product tour libraries, weeding out the abandoned projects and focusing on tools that real teams are using and updating in 2026. Whether you're building for vanilla JavaScript, React, Vue, or a framework-agnostic approach, we've got specifics on what works, and we'll be honest about when a library is the right answer—and when it isn't.

What's Changed Since 2022

The 2022 landscape was crowded with experimental and hobby libraries. Today's field is cleaner but more specialized. Several factors have shifted the game:

Maintenance reality. Hopscotch, Trip.js, and a handful of others have gone quiet. GitHub last-commit dates matter more than ever. If a library hasn't been touched in 18 months and your framework just released a major version, you're on borrowed time.

TypeScript adoption. Driver.js was built in TypeScript from the ground up. Intro.js added TypeScript definitions. Framework-agnostic libraries now understand that typed code reduces integration friction. This wasn't table-stakes in 2022.

Analytics as a feature. Onboarding without metrics is guesswork. Tools like OnboardJS now integrate with Posthog and Mixpanel out of the box, tracking where users drop off in your flow. Your analytics platform can see step_completed, step_skipped, and flow_abandoned events automatically. This shifts decision-making from hunches to data.

No-code and headless divergence. The market has split: full-stack tools like Appcues and Pendo handle everything (design, deployment, analytics) but cost money and live outside your codebase. Open-source JavaScript libraries are now laser-focused on the code layer. If you want to manage tours inside your app code with total control, open source wins. If you want a visual builder and don't mind hosting elsewhere, no-code is faster.

Next.js specificity. Onborda exists because Next.js became the default React framework. Similar patterns are emerging for other frameworks. This is healthy—specialized libraries can optimize for specific constraints (like ISR and SSR).

When a JavaScript Library Isn't Enough Anymore

Most teams start with a JavaScript library. It's the right call—low friction, no external dependency, full code control. But as your onboarding program matures, you'll likely encounter one or more of these pressures:

Governance. Who decides what tours go live? If it's the engineering team, you're bottlenecked on deploys. If it's the product or marketing team, they need to edit code. Who owns version control? Who reviews tours before they ship? What happens when a tour breaks in production? A JavaScript library puts all this on your code review process, which works until it doesn't. You need formal approval workflows, role-based permissions, and audit trails.

Look and feel. A JavaScript library gives you styling hooks, but you're still constrained by the library's architecture. Want animations that feel completely native to your product? Want tours that seamlessly integrate with your design system in ways the library didn't anticipate? You're writing custom CSS and fighting the library's defaults. As your tours become more sophisticated, those styling constraints compound. You want to hand tour design to your design team, not ask engineers to implement one-off CSS hacks.

Timing and coordination. Launching a new feature means coordinating your tour with the feature's release. You want to A/B test two variations of your onboarding. You want to show different tours to different user segments without writing conditional logic in your code. You want to schedule tours to appear only after users have completed a prerequisite step. A JavaScript library can do these things, but they require code changes and deploys. A dedicated tool lets your product team make these decisions independently, on their own timeline.

Analytics disconnect. You can wire your library to fire events to your analytics platform. OnboardJS and a few others do this automatically. But that event data lives separately from your core product analytics. Your analytics tool sees "user_clicked_tour_step_2" but not the full context of what the user was trying to do. Your tour completion rate might be 80%, but your analytics tool doesn't know that. You end up with fragmented data and spend time stitching insights together instead of acting on them.

When one or more of these problems feels familiar, you've likely hit the inflection point. That's when a dedicated product tour tool becomes the right answer—not because a library is bad, but because your company has matured past the point where a library solves your real problems.

Chameleon is built for teams at exactly this stage. It started as a solution for the governance problem (non-engineers can create and edit tours without code changes, with role-based approval workflows), but it's evolved to handle all four. Chameleon's Copilot feature uses AI to generate tour copy and structure, speeding up creation. Tours live in a hosted platform with full analytics integration—your data flows into the same analytics tool the rest of your product uses. You can target by segment, schedule tours, and A/B test, all without touching code. If your team is already testing onboarding with a JavaScript library and hitting these scaling problems, Chameleon is the natural next step.

The Current Best Options

Driver.js

What it is: A lightweight, TypeScript-native library for highlighting UI elements and attaching contextual callouts. Built with zero external dependencies.

Pros: Smallest bundle footprint among serious contenders. Modern API. Excellent keyboard navigation and accessibility out of the box. Strong documentation. Works identically across all frameworks because it's framework-agnostic.

Cons: Smaller community than Intro.js (still growing rapidly though). Fewer third-party tutorials online. Some edge cases with positioning on complex layouts require manual tweaking.

Best for: New projects that prioritize performance. Teams using TypeScript. Projects where bundle size is a constraint. Vanilla JavaScript or framework-agnostic setups.

GitHub activity: Very active. Regular updates and maintenance.

Intro.js

What it is: The old guard. A lightweight, framework-agnostic library that's been around since 2013. Intro.js is 12.5 KB uncompressed and has no external dependencies.

Pros: Battle-tested in thousands of production apps. Extensive documentation and third-party content. Large community. Backward compatible across versions. Works with every framework. Free open-source tier plus optional paid "Intro.js Studio" for visual authoring.

Cons: API is older and sometimes feels clunkier than newer libraries. Less modern TypeScript support compared to Driver.js. Community-driven features sometimes move slowly compared to commercially-backed alternatives.

Best for: Teams already using Intro.js (switching cost outweighs benefits). Projects where "boring but reliable" matters more than cutting edge. Shops that want free forever with no vendor lock-in.

GitHub activity: Active but steady. Releases tend to be quarterly rather than monthly.

Shepherd.js

What it is: A JavaScript library for creating product tours that uses Floating UI (formerly Popper.js) for positioning popover dialogs. Designed for tours that need pixel-perfect control over where tooltips appear.

Pros: Excellent for complex tours with many steps and position constraints. Strong positioning engine. Good TypeScript support. Works across frameworks. Flexible styling and customization.

Cons: Relies on Floating UI as an external dependency. Slightly larger bundle than Driver.js or Intro.js. More configuration required upfront if you want full customization.

Best for: Tours where positioning matters—think multi-step processes with forms, modals, and side panels. Teams that already use or are comfortable with Popper.js ecosystem.

GitHub activity: Actively maintained. Releases several times per year.

React Joyride

What it is: Purpose-built for React with hooks support, callback management, and React component integration throughout. Over 4,300 GitHub stars.

Pros: Deeply integrated with React patterns. Hooks-based API. Good accessibility. Easy callback wiring for analytics and flow control. Excellent documentation specific to React.

Cons: React-only (useless for Vue or vanilla JavaScript). Larger bundle if you're already shipping React (but that's a framework choice, not a Joyride issue).

Best for: React shops that don't mind the opinionated API. Teams building complex, interactive onboarding flows. Projects where React-specific hooks and component patterns matter.

GitHub activity: Actively maintained. Regular releases.

Onborda

What it is: A modern library designed specifically for Next.js apps, powered by Framer Motion for animations. Newer entrant to the space (emerged around 2023-2024).

Pros: Optimized for Next.js patterns (App Router, server components friendly). Smooth animations out of the box. TypeScript-first. Growing community. Works great for static analysis and pre-rendering.

Cons: Next.js only (not useful for other frameworks). Smaller community and fewer third-party resources than established options. Newer means less battle-tested at enterprise scale.

Best for: Next.js-first teams. Projects where animations and modern React patterns are requirements. Shops already using Framer Motion.

GitHub activity: Active and growing.

OnboardJS

What it is: Takes a different architectural approach. Instead of attaching tooltips to DOM elements, OnboardJS provides a state machine for managing onboarding flows. You bring your own UI components and design.

Pros: Incredible flexibility. Not locked into predefined tooltip styles. Integrates with analytics platforms (Posthog, Mixpanel, Supabase) automatically. Great for teams that want the framework but custom UI. Headless approach means it works with any front-end tech.

Cons: Requires more setup because you're building UI components yourself. Less "batteries included" than other options. Smaller community.

Best for: Teams with strong design systems. Projects that need custom, branded onboarding flows. Shops already using one of the supported analytics platforms. When your design system is a competitive advantage.

GitHub activity: Active and well-maintained.

When to Use a JavaScript Library vs. No-Code Tools

You should reach for a JavaScript library if:

• Your tours are part of your product code and deploy with every release

• You need programmatic control over when tours trigger based on user state

• Your design system is internal and custom

• You want all code in one version-controlled repository

• You prefer open-source with zero vendor lock-in

You should use a no-code tool (Appcues, Pendo, Chameleon, UserGuiding) if:

• You want to ship tours without code changes

• Analytics and A/B testing are table-stakes requirements

• Non-technical team members need to edit tours

• You need advanced segmentation and targeting

• You're OK with external hosting and some vendor dependency

Honest take: most production products use a no-code tool, not a JavaScript library. That's not a knock on libraries—it's just that the operational overhead of managing tours in code is higher than managing them in a hosted platform. Use a library if you have specific technical constraints that make it the better choice.

Framework-Specific Recommendations

Vanilla JavaScript or framework-agnostic: Driver.js or Intro.js (both are excellent; Driver.js is newer, Intro.js is proven).

React: React Joyride if you want React-specific hooks and patterns. Driver.js or Intro.js if you want framework-agnostic. Onborda if you're specifically on Next.js.

Vue: Driver.js or Intro.js (both work fine). The Vue-specific options from 2022 are mostly stale now.

Angular: Driver.js or Intro.js (both framework-agnostic). Angular-specific libraries haven't seen active development.

Svelte: Driver.js or Intro.js. No major Svelte-specific options exist, so framework-agnostic is your best bet.

Bundle Size and Performance

If bundle size is a hard constraint:

• Driver.js: ~20 KB minified (smallest serious option)

• Intro.js: ~12.5 KB uncompressed, ~4-5 KB minified/gzipped

• Shepherd.js: ~30 KB (includes Floating UI)

• React Joyride: ~50 KB (includes React-specific code)

For context: a typical large-scale React app is already 100-300 KB minified/gzipped. A tour library's contribution is usually <5% of total payload.

Red Flags: Libraries to Avoid or Proceed Carefully

• No commit in the last 18 months? That's stale for web libraries.

• TypeScript definitions missing? Friction for modern teams.

• No issue responses for 3+ months? Dead project.

• Dependencies on outdated packages? Security and compatibility risk.

• Requires jQuery? Hard pass unless you're on a legacy codebase.

Specific projects in this category: Trip.js, Hopscotch (archived), old versions of Bootstrap Tour.

Migration Path If You're On an Old Library

If you're currently running Hopscotch or Trip.js, migration is straightforward:

1. Map your existing tour steps to the new library's API (usually 10 minutes per tour). 2. Run both libraries in parallel for one deploy. 3. Redirect old tour requests to the new library using feature flags. 4. Remove old code once you've monitored for a few days.

Most libraries have similar core concepts (steps, highlights, positioning), so the logic porting is usually copy-paste-and-tweak work.

Making the Choice: A Decision Matrix

| Priority | Best choice | |---|---| | Smallest bundle size | Driver.js | | Most battle-tested | Intro.js | | Complex positioning needs | Shepherd.js | | React-native patterns | React Joyride | | Next.js optimization | Onborda | | Custom UI + analytics | OnboardJS | | Framework-agnostic safety | Intro.js |

FAQ

Should I use an open-source JavaScript library or a no-code tool like Chameleon?

It depends on your constraints. JavaScript libraries live in your codebase and deploy with your app—great for tight integration, but you own the operational burden. No-code tools like Chameleon are hosted externally and managed through a UI—faster to ship, better analytics, but less code control. If your team includes non-engineers who need to edit tours, no-code wins. If your tours are deeply tied to internal product state and versioning, a library wins. Most teams end up hybrid: a library for core onboarding flows and a no-code tool for ad-hoc feature highlights.

When should I move from a JavaScript library to a dedicated tool?

Start with a library if you're early stage—they're easy to ship and you have full control. But watch for these signals that you've outgrown one: (1) You're tired of code-reviewing tour changes and want non-engineers to update tours independently. (2) Your tours need more sophisticated styling or animations than the library allows. (3) You're writing complex conditional logic to target tours to specific user segments or moments in their journey. (4) Your analytics tool sees a gap between what your library is tracking and what your product metrics show. If two or more of these resonate, it's time to look at a dedicated tool. You've tested onboarding with a library, proven it works, and now you need something that scales with your team and complexity.

What's the difference between Intro.js and Driver.js, and which should I pick?

Intro.js is older, more widely used, and battle-tested in thousands of production apps—if you want the safest choice, pick Intro.js. Driver.js is newer, built in TypeScript, has a smaller bundle, and feels more modern—if you're building something new and performance matters, pick Driver.js. They're both excellent. If forced to pick for a greenfield project, Driver.js edges ahead. If you want the project that will still be maintained in 2030, Intro.js has the longer track record.

How do I add analytics to tour completion and dropout?

Framework-agnostic libraries don't ship with built-in analytics. You'll wire it manually using callbacks. For example: when a user clicks "next," trigger a Posthog event. OnboardJS is the exception—it auto-tracks events for supported platforms. If analytics is critical, either choose OnboardJS or plan to write your own event emitters in the tour callbacks.

Can I use a product tour library with a single-page app (SPA) that uses client-side routing?

Yes, but you need to be thoughtful. Most libraries attach listeners to DOM elements. If routing unmounts and remounts elements, you'll need to reinitialize tour steps or use a router-aware library. Next.js (handled by Onborda) and React (handled by React Joyride) have solutions baked in. For vanilla SPAs, you'll need to hook into your router's navigation events and reinit when needed.

What if I need to show different tours to different user segments?

JavaScript libraries don't have built-in segmentation. You'll write conditional logic in your code: if user.plan === 'enterprise', show tour A; if user.isNew, show tour B. If you need segment logic without code changes, no-code tools excel here. That said, a simple if-statement in JavaScript is often enough.

Is there a mobile-friendly product tour library?

Most libraries work on mobile, but few are optimized for it. Touches replace clicks, small screens change positioning, and keyboard navigation shifts. Driver.js and Intro.js work on mobile but require testing. If mobile onboarding is core to your product, a no-code tool often has better mobile UX built in. For libraries, test on actual devices and consider using simpler tours (fewer steps, larger touch targets) on mobile.