ScrollFlow

Auto-Scroll Screen Recorder for Smooth Webpage Captures

Visit Website
August 16, 2026 See ScrollFlow in Action: Smooth Auto-Scroll Recording

Here’s what ScrollFlow can do for you.

No more jerky manual scrolling or missed content. Just smooth, hands-free webpage recordings every time.

Perfect for:

  • UX/UI designers capturing portfolios

  • QA testers recording bug reports

  • Marketers creating demos

Comment

August 16, 2026 The Story Behind ScrollFlow: From Frustration to Solution

I spent years struggling to capture smooth, professional videos of my web designs and demos. Manual scrolling was a nightmare, and tools like After Effects were overkill for what I needed.

So I built ScrollFlow, a Chrome extension that auto-scrolls AND records webpages locally, with no cloud, no tracking, and no hassle. Now, I use it every day to create perfect captures for my portfolio, bug reports, and client demos.

If you’ve ever faced the same frustration, give it a try and let me know what you think!

Try ScrollFlow here

9 Comments

  1. 1
    video makes sense when the interaction itself matters, but plenty of these use cases just need a still that shows the full page, sending someone a video to review a documentation page is slower than it needs to be. a scrolling screenshot covers that without playback, slimsnap.ai folds a sticky nav bar into one clean shot instead of repeating it down the page. different job, so both probably belong in the same toolkit.
    1. 1

      ScrollFlow already does this natively... no separate sticky-nav folding tool needed.

      During full-page PNG capture, ScrollFlow automatically detects duplicated sticky navbars and removes the repeated instances below, while keeping the navbar visible once at the top. No manual setup. No extra tool. No repeated sticky header artifacts.

      It also stays 100% local, which is pretty important when capturing sensitive dashboards or NDA-protected pages.

      So for this use case, ScrollFlow already has it covered natively. 😉

      1. 1
        Fair. If it spots the repeat and keeps the top one, that is the same outcome. Disclosure so it is not weird, I build SlimSnap.ai. The difference is what each one can point at. ScrollFlow is a Chrome extension, so it has the DOM and can hide an element by selector before the shot. SlimSnap.ai has no DOM, it works from pixels, so it has to spot the repeat visually. Harder to get right, but it also means it can shoot an iOS simulator or a native desktop dashboard, which an extension cannot reach. Local is true on both sides, no account either way, so that one is not really the dividing line.
        1. 1
          Appreciate the transparency! Always respect a founder who ships and engages directly. You're absolutely right about the DOM vs pixels tradeoff — that's the core architectural difference. Having DOM access means we can do surgical element removal (CleanView) before the stitch, which gives us pixel-perfect control over what stays and what goes. Your pixel-based approach is indeed harder to get right, but I see the appeal for non-web targets like iOS simulators or native desktop apps. That said, for the 95% use case where devs, PMs, and designers are capturing websites (landing pages, dashboards, documentation, bug reports), having DOM access is a massive advantage. We can hide cookie banners, chat widgets, and sticky navs before the capture even starts. No visual heuristics, no edge cases where the algorithm misidentifies a repeated element. And you're right that 'local' isn't the dividing line if both tools are client-side. The real difference is precision vs universality. SlimSnap trades precision (DOM control) for reach (any screen). ScrollFlow trades reach (Chrome only) for precision (surgical DOM manipulation + automatic stitch cleanup). Different tools for different jobs, absolutely. But for the vast majority of web capture workflows, having that DOM-level control makes ScrollFlow the sharper scalpel. 🎯 Good luck with SlimSnap =) always great to see more builders tackling the capture space!
  2. 2

    The personal use case makes the origin of ScrollFlow easy to understand. Curious which of the three use cases ends up being the most common in practice.

    1. 1

      Thanks! Right now, the strongest traction seems to come from web designers and agencies showcasing modern, graphic-heavy sites (like WebGL / Three.js) for their portfolios and social media. Having a smooth capture in custom dimensions is a huge time-saver for them.

      That said, I'm still actively gathering feedback from current users to see if another use case takes the lead over time!

      1. 1

        That makes sense. The agency/web designer use case sounds like a strong early signal. If you’re open to continuing the conversation, what’s the best email to reach you at?

        1. 1

          Thanks! I can't post my email address directly in the comments here, but you can check out the product page and contact me via the support email listed there. I'll get back to you right away!

          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.

About

I built ScrollFlow after years of struggling with shaky webpage recordings. As a web designer, I needed a simple, local tool to capture my work perfectly. Now, I share it to help others avoid the same frustration.