Interactive Tour Builder | Create No-Code Guided Website Tours & Product Walkthroughs

Guide Every User Step-by-Step — Create seamless interactive tours and product walkthroughs effortlessly.

Build lightning-fast interactive website tours with the ultimate interactive tour builder. Paste any HTML, auto-detect elements, live preview, drag-and-drop steps, and export 100% self-contained production code. Perfect for SaaS onboarding, e-commerce demos, and premium conversions.

 

Last Updated: August 2026

🔴 Four Tabs, and Why Each One Exists

Most tour builders let you write steps and hand you a JSON file. The hard parts are everywhere else: knowing whether your selectors still match after a redesign, deciding whether a tour is even the right pattern, and getting working code out at the end rather than a config file you still have to wire up.

Build — write the steps against real markup

Paste the HTML of the page you are writing a tour for, or pick one of the three samples. Press Render stage and it appears in a sandboxed panel below the editor. Scripts, iframes and inline event handlers are stripped before anything renders — you are usually pasting markup from a page you did not write, and a preview pane is no place to execute someone else’s JavaScript.

From there, three ways to create steps:

🔵 Pick element turns the cursor into a crosshair. Click anything on the stage and a selector is captured for you. It prefers an id, then a data-tour attribute, and only falls back to a structural path when neither exists.

🟠 Auto-detect walks the markup for buttons, inputs, selects and linked elements, and drafts a step for each with the element’s own label as the title. It caps at eight, because it is a starting point to cut down rather than a finished tour.

🟣 Add step by hand when you already know the selector.

Each step carries a bubble position, an advance trigger — press Next, click the element, or fill the field — and two switches worth understanding. Scroll into view matters on long pages. Skip if the element is missing is what you want for a step pointing at something that only appears for some users, such as an admin-only control.

Preview & Test — where tours actually break

Run the tour at mobile, tablet or full width. This is not decoration. A bubble set to appear to the right of an element looks correct on a desktop and falls straight off a 380 pixel screen, and that is the single most common way a tour ships broken.

The selector health table underneath is the part worth running before every release. It reports three states:

🔵 Good — the selector matches exactly one element.

🟠 Ambiguous — it matches several. The tour will highlight the first one, which is not always the one you meant. A selector like .card .title looks specific and matches nine elements on a listing page.

🟣 No match — the step will be skipped in silence. Nothing is logged, no error appears, and the tour looks like it worked while quietly missing a step.

That last case is why the check exists. A broken tour does not announce itself.

Hotspots & Checklists — for people who already dismissed the tour

A tour suits a first session and almost nothing after it. Someone who has already pressed Skip once will press it faster the second time. Three quieter patterns work better for returning users:

Hotspots are pulsing markers anchored to an element. They wait to be noticed instead of demanding attention, which makes them right for a feature that is genuinely useful but not urgent.

Checklists work because progress is visible and resumable. Three of five done is a much stronger pull than a tour that has to be restarted from step one. Tick items in the editor and the preview widget updates as you go.

Announcement banners are for one job only: something changed. One sentence, and let people close it for good.

Export & Embed — working code, not a config file

Five formats. JSON is the definition alone, for when you already have a tour library. Standalone JavaScript is self-contained — markup, styles and logic in one file with no dependencies — and is the one most people want. React and Vue 3 come out as components with the steps inlined. WordPress gives you a shortcode function to drop in a snippet plugin.

Two options change what the export contains. Analytics hooks fire a custom DOM event on every step shown, completed or skipped, and push the same to dataLayer if one exists — the step people quit on tells you which part of your product is confusing far better than a completion rate does. Remember dismissal writes a flag to local storage so a returning visitor is not shown the tour again.

The generated JavaScript is plain ES5, keeps the bubble on screen when an element sits near an edge, repositions on resize, and supports Escape to quit plus arrow keys to move. Paste it before the closing body tag and it runs.

🟡 Mistakes Worth Avoiding

Building the tour on class names

This is the one that costs people real time. A selector such as .btn-primary.large works perfectly until a designer renames a utility class, and then the tour breaks with no error anywhere. Add a dedicated attribute to the elements you point at:

<button data-tour="upload">Upload file</button>

and target [data-tour="upload"]. The attribute exists for exactly this purpose, so nobody removes it during a redesign. The picker in this tool already prefers it when one is present.

Making the tour too long

Five steps is a sensible ceiling. Past that, completion drops sharply — people arrived to do something, not to read a manual, and every additional step is another chance to press Skip. If you genuinely have twelve things to explain, a checklist is the right pattern, not a longer tour.

Explaining the obvious

A step over a button labelled Save teaches nobody anything and spends the goodwill you needed for the step that mattered. Point at the setting buried three menus deep, the field whose format is not obvious, the feature nobody finds. Those earn the interruption.

Never testing on a phone

Covered above, but it bears repeating because it is so common. Run every tour at mobile width before shipping. If a bubble is positioned left or right of an element, check it especially carefully.

🟢 Honest Limits

The stage is a static preview. Pasted scripts are stripped, so a step whose selector only exists after a modal opens or a tab is clicked cannot be tested here — check that one on the real page.

The selector health check only knows about the markup you pasted. If your live page differs, the check will pass while the tour still breaks. Paste the current markup, not last month’s.

Auto-detect stops at eight steps and reads element text for titles, so a button whose label is an icon gets a poor title. Edit them.

Everything is held in the page while you work. There is no account and nothing is saved to a server, which means a refresh loses your tour — export the JSON before you close the tab. You can import it back from the Export tab whenever you need it.

🔴 Going Deeper

If you want to know why spotlight overlays are built the way they are, how element positions are calculated, and what the research actually says about onboarding completion, the companion piece covers it: how product tours work under the hood.

To build or edit the page the tour runs on, the Offline HTML Editor is the companion tool here. The selector syntax itself is documented at MDN’s querySelector reference, and Nielsen Norman Group’s research on onboarding tutorials is worth reading before you write the first step.

❓ Frequently Asked Questions