A no-code alternative to Intro.js, Shepherd.js and Driver.js

Clew vs a tour library, point by point

Comparison based on public information as of September 2026 — the vendors' own pricing, product and help pages. Features and prices change; if something here is outdated or inaccurate, email hello@getclew.io and we will fix it.

What tour libraries do well

• Full control. The tour is your code: any markup, any styling, any behaviour you are willing to write.
• No external service. The library ships in your bundle. There is no vendor script, no vendor account, and nothing leaves your app.
• Versioned with the product. A tour changes in the same pull request as the screen it describes, and code review sees both.
• Low cost to start. Driver.js is MIT-licensed; Intro.js and Shepherd.js are free under the AGPL, with commercial licences for commercial use.

Where a library stops

None of this is a flaw in the libraries: it is simply outside what a library does. But it is the work that decides whether onboarding improves after launch.

• Every copy change is a release. A product manager who wants to reword step 2 files a ticket and waits for the next deploy. In practice the first draft becomes the final version.
• Targeting is your code. “New users only”, “admins on the billing page”, “once per person”, “on the third visit”: each rule means code plus somewhere to store who has already seen what.
• No analytics. To know how many people finish the tour, or which step loses them, you wire events into your analytics and build the funnel yourself.
• No A/B tests. Comparing two versions of a tour means assignment logic, sticky variants and a significance calculation — a small project of its own.
• Silent breakage. When a redesign renames a class, the step loses its element. Nobody notices until a user complains.
• Only developers can touch it. The people who see the problem — support, product, marketing — can’t fix it themselves.

When Clew fits better

• Non-developers should build and edit tours, tooltips, modals and checklists on the live page, without a release.
• You want per-step funnels and alerts when a step can’t find its element after a front-end release.
• You want to A/B test two versions of a tour and keep the one that gets finished more often.
• You need targeting by page, user property, trigger and frequency without writing it.
• You still want control over data: Clew can run on your own servers (self-hosted).

Clew is web-only and loads as one script from its own URL; it is not a library you import.

Moving a library tour to Clew

1. Keep your anchors. If your steps point at data-tour attributes, leave them: the Clew editor picks them first when you click an element.
2. Add the script tag once, in the root HTML or the root layout of your app. In a single-page app the widget follows route changes itself; the React install guide shows Vite, Create React App and Next.js.
3. Rebuild the steps in the editor: click each element on the live page and paste the copy from your old tour definition.
4. Replace the start call. Tours usually start by themselves from the page and audience rules. If a button (“Take the tour”) launched the old tour, call Clew instead:

document.querySelector('[data-tour="take-tour"]')
  .addEventListener('click', () => Clew.show('welcome-tour'));

5. Remove the library and its styles once the new tour is published.

Why teams pick Clew

Frequently asked questions

Read next