TLDR: AI builds interactive pages just as easily as static ones, but only if you ask for the behavior instead of only the look. Use one small pattern for every moving part: name the trigger (what the user does), name the change (what happens on the page), and name the state (what stays true afterward). Below are copy-paste prompts for tabs, filters, toggles, live calculators, accordions, and forms that respond, plus how to fix an interaction that breaks and how to keep it working when you share the page.
You asked AI for a page and it delivered something that looks finished. Clean layout, nice type, sensible colors. Then you click a tab and nothing happens. You type in the search box and the list ignores you. The “calculator” shows a number that never changes. The page looks alive and behaves like a poster.
That gap is the single most common disappointment with AI-generated pages, and it is almost never the model’s fault. Modern models write working JavaScript fluently. The reason your page is inert is that your prompt described how it should look and stayed quiet about what it should do. To make an AI page interactive, you have to ask for the behavior on purpose. This guide gives you the pattern and the copy-paste prompts to do exactly that.
Why AI pages come out static by default
When you say “build me a page with three pricing tiers and a monthly and annual option,” the model has two ways to read it. One is a picture: draw three cards and a toggle control. The other is a behavior: draw three cards and a toggle that actually changes the prices. If you did not specify the second reading, you usually get the first. The model optimizes for the thing you named, and you named the appearance.
Interactivity is not a harder kind of code for AI to write. A filter, a tab switch, a live total, these are the most common patterns on the web, and models have read millions of them. The browser already ships with everything needed to run them. What is missing is the instruction. You have to tell the AI that the control is not decoration.
The good news is that once you know the shape of the instruction, every interactive feature follows the same recipe.
The anatomy of an interactivity prompt
Every moving part on a page is the same three-step loop: someone does something, the page changes, and a new state holds until the next action. Name all three and the model has everything it needs.
- Trigger. What the user does. Clicks a tab, types in a box, drags a slider, checks a box, submits a form.
- Change. What happens on the page in response. Show a panel, hide the cards that do not match, recalculate a total, reveal an error message.
- State. What stays true afterward, and how it resets. The active tab stays highlighted, the filter stays applied until you clear it, the total reflects the current inputs.
Here is the difference in one line. A weak prompt says “add a filter bar with tags.” A strong one says “add a filter bar with a button for each tag; clicking a tag (trigger) hides every card that does not carry that tag (change), keeps the tag highlighted, and shows a Clear button that brings all cards back (state).” Same feature, but the second version tells the model to wire it up.
Copy-paste prompts for the interactions people actually want
Each prompt below is written the way you would paste it into Claude, ChatGPT, or Gemini. Add them to an existing page (“here is my page, add…”), or fold them into a first build. They assume you want self-contained output, which matters for keeping the behavior intact later. If you are starting from scratch, read how to get self-contained HTML from AI first.
Tabs and switchable sections
Add a tabbed section to this page with three tabs: Overview, Features, and FAQ.
Clicking a tab shows only that tab's panel and hides the others, and marks the
clicked tab as active with an underline. The first tab is active on load. Use a
single set of buttons and panels, wire it with plain JavaScript and
addEventListener, no libraries. Keep the tabs usable by keyboard.Filter or search a list
I have a grid of project cards, each with one or more tags. Add a filter bar
above the grid with a button for each unique tag plus an "All" button.
Clicking a tag shows only the cards that have that tag and hides the rest;
the active tag stays highlighted; "All" resets to showing everything. Also
add a search box that filters the cards live by title as I type. Plain
JavaScript, inline, no dependencies.A toggle (dark mode, monthly and annual, unit switch)
Add a toggle at the top labeled Monthly / Annual. When it is on Annual, every
price on the page switches to its annual number and shows a "save 20%" badge;
on Monthly it shows the monthly number and hides the badge. Store the two
prices for each plan as data attributes so the toggle just reads them. Default
to Monthly. Vanilla JavaScript, no framework.A live calculator
Add a small calculator to this page. Inputs: a number field for "hours" and a
number field for "hourly rate," plus a dropdown for "rush job" (adds 25%).
Below the inputs, show a total that updates the moment any input changes, no
submit button. Format the total as currency and never show a negative number.
Keep all the logic in inline JavaScript with addEventListener on input events.For a full worked example of this pattern, see build a pricing calculator with AI.
An accordion or FAQ
Turn this list of questions and answers into an accordion. Each question is a
button; clicking it expands its answer and collapses any other open one, so
only one answer is open at a time. Rotate a small chevron on the open item.
Start with all answers collapsed. Animate the open and close smoothly. Inline
CSS and JavaScript only.A form that responds
Make this contact form validate before it "submits." Require a name and a
valid-looking email; if either is missing or wrong, show a red message under
that field and do not proceed. When both are valid, hide the form and show a
"Thanks, we'll be in touch" confirmation in its place. Do all of this in the
browser with plain JavaScript, no backend calls.A quick note on feel: interactions land better with a little motion, a panel that fades in rather than snapping. Keep it subtle. Adding animation to an AI page covers how to ask for motion that helps instead of distracts.
Describe the outcome, not the mechanism
The most reliable interactivity prompts describe what the user experiences, not how to build it. You are the product person here, not the engineer. Compare the two columns below. The left is how people often prompt, and why it produces dead pages. The right is the same intent expressed as behavior.
| You want | Weak prompt (look only) | Strong prompt (behavior) |
|---|---|---|
| Tabs | “Add three tabs at the top” | “Clicking a tab shows its panel and hides the others; first tab active on load” |
| Filter | “Add tag buttons above the cards” | “Clicking a tag hides cards without it; Clear brings them all back” |
| Toggle | “Add a monthly/annual switch” | “Annual swaps every price to its annual number and shows a savings badge” |
| Calculator | “Show a price estimate” | “Recompute the total live as any input changes, formatted as currency” |
| Accordion | “Make the FAQ collapsible” | “Clicking a question opens its answer and closes any other open one” |
Notice the pattern. Every strong prompt names a trigger verb (clicking, typing, changing) and the visible result. You never once mention a function, a variable, or an event name. That is the model’s job. Yours is to be precise about the experience.
How to fix an interaction that does not work
Sometimes the first build gets the look right and the behavior wrong. The button does nothing, or the filter hides everything, or the total will not update. Resist the urge to say “the filter is broken” and regenerate the whole page. A vague complaint gets a vague rewrite that often breaks something else.
Instead, describe the failing loop the same way you described the feature. Name the trigger, the current (wrong) behavior, and the behavior you expect:
When I click the "Design" tag, nothing changes; all cards stay visible.
Expected: only cards tagged Design stay, the rest hide, and the Design button
stays highlighted until I click it again or click All. Please fix just that
behavior and leave the layout and styling as they are.That last sentence matters. Telling the model to change only the behavior and leave the rest alone keeps a small fix from turning into a redesign. This targeted-feedback habit is the whole skill of working with AI on pages; there is more of it in how to iterate on AI-generated pages and follow-up prompts to polish an AI page.
Keep the interactivity when you share the page
Here is the part that catches people at the finish line. You finally have a page where the tabs switch and the calculator counts. Then you send it, and it dies on the way.
A screenshot freezes it into an image. A PDF flattens every control into a picture of a control. Even the raw HTML file often loses its behavior, because the recipient downloads it, opens it from a random folder, and the JavaScript that made it move is somewhere it cannot reach. The interactivity was real. The delivery killed it.
Two habits keep it alive. First, always ask for one self-contained HTML file with all CSS and JavaScript inlined and no external libraries, so the behavior travels with the page. Second, share it as a live page instead of a file. That is where VisiblePage fits: paste the HTML, or drop a ZIP if the AI split the project into files, and you get a live URL where every tab, filter, toggle, and calculator keeps working for anyone who opens it. The page runs for real because you are sharing the real page, not a picture of it. It loads fast from the edge, you can make it public, private, or password-protected, and when you change a number the same link updates, so there is never a “final_v2” to send around.
Try it now: Publish your AI-generated HTML with VisiblePage and get a live link where every interaction still works.
Frequently asked questions
Can AI add real interactivity to a page, or just static layouts? It can add real interactivity. Tabs, filters, search boxes, toggles, live calculators, accordions, modals, and form validation are all standard browser behavior that AI writes fluently in plain JavaScript. The trick is asking for the behavior, not just the look. Describe what should happen when someone clicks, types, or drags, and you get a page that responds.
Why does the interactivity break when I move the code somewhere else? Usually because the JavaScript got separated from the HTML, or an external library the page depended on did not come along. Ask for one self-contained HTML file with everything inlined and no external dependencies, and the interactive parts travel with the page.
How do I get the AI to fix an interaction that does not work? Name the trigger, the current behavior, and the wanted behavior. “When I click the Design tag, nothing changes; it should hide the non-Design cards” gets a targeted fix, while “the filter is broken” gets a risky rewrite.
Do I need to know JavaScript to prompt for interactive features? No. You describe the behavior in plain language and the AI writes the code. Think like a user: name what someone does and what should change as a result. You never name a function or an event listener yourself.
How do I share an interactive page so the buttons still work? Publish it as a live page rather than sending a screenshot, PDF, or raw file. Publishing to VisiblePage gives you a live URL where every tab, filter, toggle, and calculator keeps working for whoever opens it.
The one habit that changes everything
If you take one thing from this: stop describing pages and start describing behavior. For every control you add, say it out loud as three sentences, the trigger, the change, and the state that holds after. That is the entire craft of making an AI page interactive, and it works the same across Claude, ChatGPT, and Gemini. Build the thing that moves, keep it self-contained, and publish it as a live link so the movement survives the trip to whoever needs to see it.