Show them where to click.

TapTrail lets you click through a page once and send the path. The other person follows it on the live page, one step at a time.

Why it exists

You know where the setting is. Someone else does not. Writing "open the avatar menu, pick Workspace settings, go to Advanced, open API access" takes longer than doing it, and the other person still has to match your words to their screen. A screenshot shows one page. A video shows your window, at your size, and goes stale the next time the layout moves.

TapTrail sits in between. You do the clicks once. They follow them on the real page, in their own browser, at their own pace. Support teams, onboarding guides, QA reports and internal how-tos are the usual places it helps; the use cases page has more.

A list of clicks

Press record and use the site normally. Each click becomes a numbered step, and the recording continues when you move to another page. Stop, give the trail a title if you like, pick how long the link should last, and you get a link.

The other person opens it and sees the same path: the page scrolls to the element, a numbered mark pulses, a dotted line joins it to the last step, and a tooltip names what was clicked. When a step is on another page of the same site, the replay goes there.

This is not a screen recording. A trail is a short list of steps — which element, which spot inside it, which page. It is a few kilobytes, and it replays at the other person's window size.

What a step holds

• A selector for the element, plus a short label taken from its name or its visible text.
• Where inside the element the click landed, and a viewport position to fall back on if the element has moved.
• The page address, and how long after recording started the click happened.

Typing into a field becomes a step too — "typed into 'Company name'" — but what was typed is not read. The follower is asked to type their own. A site can opt a field in with data-tt-record so a trail can keep its text, for things like a sample project name, and the person recording then chooses Keep or Leave out when they start; passwords, card numbers and one-time codes are never kept either way. Email addresses and long numbers are masked in labels and page titles, and address parameters that look like credentials are dropped. The privacy page has the full list.

Finding the element again

Pages change between the recording and the replay. Each step is looked up in three ways, in order:

• The stored selector. It prefers things that stay put, such as a hand-written id, a data-testid, a name or an aria-label, and only falls back to "the third item in this list" when nothing better exists.
• An element with the same tag and label, if the selector now points somewhere else.
• The viewport position recorded at the time. A step found this way shows a grey marker and says so, so nobody mistakes a guess for a match.

Following a trail

A replay has previous, play and pause, next, and three speeds. A bar along the bottom has one segment per step, split where the page changes. The arrow keys and space move through it, and Esc leaves.

By default a replay only points. Turn on auto-tap and moving to the next step clicks the current one first, so a menu opens before the step inside it and a link carries the replay to the next page. Auto-tap only presses links within the same site, tabs, section headers, and buttons that say they open something. It refuses anything whose label reads like a change — delete, remove, revoke, rotate, reset, pay, send, publish, sign out and the like — and leaves it for the person to click. When it refuses, it says why and waits. At a typing step it puts the cursor in the field and waits for you to type, unless the field is opted in and you have not typed in it yet, in which case it fills in the recorded text. Once you move past a typing step, its text is filled in even with auto-tap off, so the page reads the way the recorder left it; text with a masked email or number is shown but never filled in. It never submits a form. And when a step is hidden inside a dialog, menu or side sheet that the step before it opens, the replay presses that opener for you if it is safe to, or tells you to do the step before first. Tabs and collapsed sections that hide a step are opened for you, and the replay controls stay usable above a native <dialog>.

How long a link lasts

A trail lasts a day unless the person recording picks another lifetime: an hour, a day, or three days. After that it is gone, and the link answers "not found". The person who recorded it can also delete it sooner. A recording that has not been saved yet lives only in that browser tab, and disappears when the tab closes.

Your server, your trails

TapTrail is a small Node program with no runtime dependencies. Whoever runs it decides where it is reachable, whether trails are written to disk or kept only in memory, how long they may last, and which sites may upload to it. There is no TapTrail account and no hosted service behind this page; the trails on this server stay on this server.

Recording can be kept to the people who should do it, such as a support team or admins. Their pages load the full script; everyone else's load it with ?record=0, which still plays shared links but shows no record button and ignores the shortcut. On the server, an upload secret means a trail is only saved when it comes with a short-lived token that your own app signed for a signed-in staff member. Following a link stays open to whoever has it.

Not yet

A trail records clicks, keyboard focus and where you typed. It does not record scrolling or choices in a dropdown, and it cannot be edited after recording. A step on a different site shows a link instead of following it. These may come later.

Try it

The demo is a pretend admin app called Lumen Console. Record a trail there, copy the link, and open it in another window. One script tag drops the same recorder onto any other page. Details are on the install section of the home page.