TLDR: Scrollytelling with AI turns the scroll bar into a narrator: short story steps move past while one pinned visual changes to match, so the page reveals itself one idea at a time. Describe the scenes and the sticky visual, ask for scroll-triggered reveals with IntersectionObserver in a single self-contained HTML file, and make sure it collapses to one column on phones. Then iterate on timing and feel the way you would with a designer, and publish the real page as a live link so the scroll effects survive.
You have seen it even if you have never named it. A news feature where a map redraws itself as you read. A product page where the phone rotates and lights up section by section as you scroll. An annual report where each number counts up right as it slides into view. That format is called scrollytelling, and it is one of the few page styles where the reader’s own scrolling becomes part of the story. The good news for anyone building with AI: it used to take a front-end specialist and a week, and now it takes a well-shaped prompt and an afternoon.
This guide is about scrollytelling with AI from the ground up. What the format actually is, when it earns its keep and when it gets in the way, the exact way to describe it so a model builds a working version instead of a jittery mess, and how to get the finished page in front of people without flattening the very thing that makes it good.
What is scrollytelling, really?
Strip away the fancy examples and scrollytelling is three parts working together:
- A pinned visual. One thing stays put on the screen while you scroll: a map, a chart, an illustration, a product shot, a full-bleed photo. In CSS this is usually
position: sticky. - Story steps. Short chunks of text scroll past the pinned visual, one idea at a time. Each is a beat in the story.
- A trigger. As each step scrolls into view, something reacts: the map pans, the chart adds a series, the image swaps, a number counts up. The reader’s scroll position is the remote control.
That third part is the soul of it. A tall page with a lot of sections is just a long page. Scrollytelling is a sequence, paced by the reader, where the visual and the words stay in lockstep. The reader is never lost, because they only ever see one idea at a time, and they can slow down or speed up as they like.
When does scrollytelling actually help?
This is the question most people skip, and it is the one that decides whether the effort is worth it. Scrollytelling asks the reader to move through your story in order, at your pacing. That is a gift for some pages and a tax on others.
It shines when the content is a narrative with a beginning, middle, and payoff:
- A product launch that reveals the thing one feature at a time.
- A case study that walks from the problem to the result.
- An annual or impact report where numbers land as they appear.
- An explainer that builds an idea layer by layer.
- A personal story, a founding story, a “how it works” tour.
It gets in the way when people came to find something, not to be told something. A pricing table, a contact page, a menu, documentation, anything reference-shaped, should let people scan and jump. Forcing those into a scroll story is like making someone watch a video to get a phone number. If your reader’s goal is to skim and leave fast, build a normal landing page with a strong hero section instead.
A quick gut check: if you can imagine someone using Ctrl+F on the page, it is not a scrollytelling page.
How do you prompt AI for a scrollytelling page?
The mistake almost everyone makes is asking for “scroll animations.” That gets you random elements fading in, which looks busy and says nothing. Scrollytelling is not decoration, it is direction. So you prompt it the way you would brief a motion designer: name the sticky visual, list the steps, and say what the visual does at each one.
Four moves turn a vague ask into a real scroll story:
- Name the sticky visual and the layout. “A visual pinned on the left that stays in view; story text scrolls on the right.” One thing holds still, the words move past it.
- Write the steps as a storyboard. Each step is a short paragraph plus a note on what the visual should show at that moment. This is the storyboard, and it is where the quality lives.
- Name the trigger, correctly. Ask for
IntersectionObserverto detect when each step enters the viewport, not ascrollevent that fires hundreds of times a second. The first is smooth, the second stutters. - Demand one self-contained file, and a mobile layout. Everything inlined, no external libraries, and a rule that the two columns stack into one on small screens. If the model drifts, our guide on self-contained HTML from AI has the exact phrasing.
Here is a full prompt you can copy, drop your own story into, and run in Claude, ChatGPT, or any capable model:
Build me a scrollytelling page as a single self-contained HTML file.
Layout: a two-column scroll story. On the left, one visual that is
pinned with position: sticky and stays centered in the viewport while
the reader scrolls. On the right, a column of short "story steps."
The story is about [your topic]. Steps, in order:
1. [First beat.] Visual shows: [state A, e.g. an empty map].
2. [Second beat.] Visual changes to: [state B, e.g. a route drawn].
3. [Third beat.] Visual changes to: [state C, e.g. markers appear].
4. [Closing beat.] Visual settles on: [final state + a headline number].
Use IntersectionObserver to detect when each step scrolls into the
middle of the viewport, and switch the sticky visual to that step's
state with a smooth transition. Do NOT use a raw scroll event listener.
On screens under 700px wide, stack to a single column: the visual sits
above each step instead of staying pinned, and effects stay light.
Style: [clean and modern / editorial / bold], one accent color,
generous spacing, large readable type. Inline all CSS and JavaScript,
no external libraries, no external images. One HTML file.Every line is pulling weight. The storyboard is the part that separates a page that means something from one that just moves. The IntersectionObserver instruction is what keeps it smooth. The mobile rule saves you the single most annoying revision. And the feel words at the end are how you art-direct without being a designer.
See it work: a scroll-reveal demo
Scrollytelling is hard to describe and easy to feel, so here is a small live version built with a few lines of pure CSS. Scroll slowly through the three steps below. In browsers that support scroll-driven animation, each one slides and fades in as it reaches your screen, exactly the effect the prompt above produces. Everywhere else the steps simply show in place, which is the graceful fallback you always want.
Set the scene
The first step establishes where the reader is. In a real scroll story, the pinned visual would show its starting state here, an empty chart, a wide map, a blank stage.
Add a layer
The second step advances the story by one idea. As it enters the screen, the visual reacts: a line appears, a region highlights, a number begins to climb.
Land the payoff
The final step delivers the point you built toward. The visual settles into its finished state, and the reader arrives at the conclusion having watched it assemble, one scroll at a time.
That demo uses a lightweight CSS scroll effect to reveal each step. A full scrollytelling page usually reaches for a small amount of JavaScript with IntersectionObserver, which can do more than fade a card in: it can swap the sticky visual, redraw a chart, or count a number up as each step arrives. The idea is the same, and it is exactly what you ask the model for in the prompt above.
Prompt patterns for common scroll stories
The storyboard changes, but the shape stays the same. Here are three starting points. Swap in your own beats.
A data story where a chart builds as you scroll:
Build a scrollytelling page as one self-contained HTML file. Sticky
visual: a single bar chart drawn in inline SVG or canvas. As each
story step scrolls into the middle of the viewport, the chart updates:
step 1 shows an empty axis, step 2 draws the 2023 bars, step 3 adds
2024 in the accent color, step 4 highlights the one bar that matters
and shows the headline takeaway. Use IntersectionObserver for the
triggers, animate the bars growing, stack to one column under 700px.
[paste your numbers]If the chart itself is the hard part, our guide on creating charts and graphs with AI pairs well with this.
A product tour that reveals features one at a time:
Build a scrollytelling product page, one self-contained HTML file.
Sticky visual: a large product mockup drawn with CSS/SVG (a phone or
a dashboard frame). Each step highlights one feature: as the step
enters view, dim the rest of the mockup and spotlight the relevant
part with a label and a short caption. Four features, four steps, then
a final step that shows the whole product and a call-to-action button.
Smooth transitions, IntersectionObserver triggers, mobile single column.An editorial story with a full-bleed image that changes:
Build a scrollytelling long-read as one self-contained HTML file. A
full-screen background visual stays fixed while story text scrolls over
it in readable cards. At each step, cross-fade the background to a new
scene and shift the mood. Keep text legible with a subtle gradient
scrim behind it. IntersectionObserver triggers, generous type, works
on mobile. Story steps: [paste your beats].Scrollytelling vs the alternatives
Scrollytelling is one way to walk someone through a story. Here is how it stacks up against the usual options, so you pick it for the right reason.
| Format | Reader controls pace | Interactive | Good for | Weak for |
|---|---|---|---|---|
| Scrollytelling page | Yes, by scrolling | Yes, fully | Narratives, launches, reports, explainers | Anything people want to skim or search |
| A normal long page | Yes | Some | Most content, fast reference | Building suspense or a guided reveal |
| A video | No, it plays at its speed | No | Passive watching | Letting readers slow down or re-read |
| A slide deck | Presenter or click | A little | Live presenting | Self-guided reading on the web |
The row that matters is the first one. Scrollytelling is the only format that is both self-paced and interactive, which is exactly why it works for a story someone reads alone on their phone.
Iterating on timing and feel
Your first build will work and feel slightly off, and that is fine. Scroll stories live or die on timing, and timing is the easiest thing in the world to tune with AI, because it is one message per pass. Give notes like a director, one change at a time:
Three tuning notes:
1. Reveal each step when it is 40% into view, not when it is almost
centered. Right now the payoff lands too late.
2. Slow the visual transition to about 700ms and ease it, so the
change feels intentional, not snappy.
3. Hold the final scene a little longer before the page ends, so the
last number has room to breathe.Words like “cross-fade,” “ease-out,” “stagger,” and “hold” are exact, and models act on them well. Keep each round short, scroll it again, repeat. Five small passes beat one giant “make it better,” and the same rhythm works for iterating on any AI page.
Two things to check every time before you call it done: scroll it on a real phone, because a two-column sticky layout that never collapses is unreadable on a small screen (our notes on mobile-friendly AI pages cover the fixes), and try it with reduced-motion turned on, so people who get queasy from movement still get the story. Ask the model to respect prefers-reduced-motion and fall back to simple fades.
Getting a scroll story in front of people
Here is where scrollytelling pages quietly die. You built something whose entire value is the scrolling, and then the obvious ways to share it destroy exactly that. A screenshot is a single frozen frame of a story meant to move. A PDF cannot scroll-reveal anything. Emailing the HTML file makes the recipient download it and hope it opens, and a scroll story is the last thing you want someone poking at as a raw file. The one thing that keeps a scroll story alive is sharing the real, running page.
That is the natural last step, and it is where VisiblePage fits. You take the self-contained HTML the AI produced, or a ZIP if the project grew into multiple files, and you get a live link on the spot: no build step, no toolchain, no server to set up. The page loads fast from the edge, and every part of the effect survives, the sticky visual pins, the steps reveal, the chart builds, because your recipient is opening the actual page and not a picture of it. You can keep it private or password-protected while you are still tuning, then flip it public. And because scroll stories always get one more revision, you re-publish to the same link and everyone who has the URL sees the update, with no “final_v3” in sight.
Try it now: Publish your AI-generated scrollytelling page with VisiblePage and get a live link in seconds.
Frequently asked questions
What is scrollytelling?
Scrollytelling is a web format where the reader’s scroll position drives the story. As you scroll, text steps forward one idea at a time while a fixed visual, a map, a chart, an image, changes to match. It turns a flat page into a guided sequence that unfolds at the reader’s own pace, and it is a natural fit for AI because the whole thing can live in one self-contained HTML file.
Can AI build a scrollytelling page?
Yes. Ask for a scroll-driven story page and name the mechanic: a sticky visual on one side, story steps on the other, and a way to react as each step scrolls into view. Modern models write the IntersectionObserver logic and the layout for you in one file. Describe the scenes and the visual, ask for a single self-contained HTML file, then iterate on timing and feel.
When should I not use scrollytelling?
Skip it when the reader wants to scan and leave fast, like a pricing table, a contact page, or reference docs. Scrollytelling asks people to move through your story in order, so it pays off for a launch, an annual report, a case study, or an explainer, and gets in the way for anything people want to search or skim.
Will a scrollytelling page work on phones?
Only if you ask for it. The sticky-visual, two-column layout has to collapse to a single stacked column on small screens, and scroll effects should stay light so they do not stutter. Put mobile behavior in your first prompt and test on a real phone before you share it.
How do I share a scrollytelling page once it is built?
Because scrollytelling is the scroll itself, a screenshot or a PDF throws away the entire point. Publish the real page as a live link so the reveals, the sticky visual, and the animation all still work. With VisiblePage you paste the HTML or drop a ZIP and get a shareable URL in seconds, with the interactivity intact.
The short version
Scrollytelling turns scrolling into storytelling: pin one visual, let short story steps move past it, and change the visual as each step arrives. Prompt it like a storyboard, name the sticky visual and the per-step reveal, ask for IntersectionObserver triggers and one self-contained HTML file that stacks to a single column on phones. Tune the timing in small passes until it feels right, respect reduced motion, and then publish the real page as a live link so the one thing that makes it special, the scroll, still works for everyone who opens it.