If you can’t scroll on a website, first isolate what the problem follows: one site, one browser, or one way of scrolling. Try a second input method and open the same page in another browser before changing settings. That quickly separates a likely site problem from a browser, extension, or input-device issue—without assuming the mouse is broken or the site’s code is at fault.
Start by identifying where scrolling fails
Note five details before troubleshooting: whether the problem affects one site or many; which browser is involved; whether you are using a mouse wheel, touchpad, touchscreen, keyboard, or scrollbar; whether the document or a nested panel is meant to scroll; and whether scrolling stops, feels delayed, or moves the background unexpectedly. These are distinct symptoms with different likely causes.
- One site, several browsers: the page itself or an embedded component is a stronger suspect.
- Several sites, one browser: look at browser settings, extensions, site data, or blocked content.
- One input method: test the device and browser’s handling of that input before blaming the page.
- Only a panel or dialog: the gesture may be going to a nested scroll area rather than the main document.
These are diagnostic clues, not proof. A page can fail for different reasons on different devices.
Try these fixes in order
- Reload once. Check whether the page is still loading or whether a dialog, menu, consent prompt, or other overlay is covering it. If a panel or embedded frame is open, try scrolling inside its content area, then outside it.
- Use another scrolling method. Try Page Down or the spacebar, drag the scrollbar, or switch between a mouse wheel and touchpad. On a phone or tablet, test touch scrolling. If only one method fails, focus on that input method and the browser settings that affect it.
- Open the same page in another browser. If it also fails there, the site is a more likely source. If the problem appears only in Firefox, Mozilla recommends continuing with Firefox-specific checks rather than treating it as a general website failure. Mozilla’s troubleshooting guide covers browser-specific checks.
- Disable likely extensions one at a time. Start with ad blockers, privacy or script blockers, and page appearance customizers. Reload the page after each change, then re-enable extensions that make no difference. An extension can alter page content or prevent scripts and other resources from loading.
- Clear site data only if the quicker checks fail. This may sign you out of the site, so use the browser’s controls for that specific site if available, then reload and sign in again if needed. Mozilla includes cached data and site settings among its page-troubleshooting checks.
- For a browser-only problem, inspect browser settings and blocked content. Check whether JavaScript or page resources are being blocked. If ordinary checks do not help, follow the browser maker’s guidance for graphics or hardware-acceleration troubleshooting instead of changing several advanced settings at once.
- Report a persistent site-only failure to the site owner. Include the page address, browser and device, input method, whether another browser changes the result, and whether the issue is a total lock, lag, or unexpected background movement.
Why a website can stop or delay scrolling
JavaScript can take over a gesture
Touch and wheel input normally let the browser perform scrolling. A page’s JavaScript can listen for those events and call preventDefault(), cancelling the browser’s default action. That can be intentional for a custom interaction, but a broad or incorrectly scoped handler can prevent ordinary page movement. Chrome’s guidance favors declaring touch behavior with the CSS touch-action property where appropriate rather than relying on JavaScript to cancel touch events.
#1 Best Overall
A wheel or touchpad gesture can also feel delayed when the browser must wait for a JavaScript handler to finish before it knows whether the handler will cancel scrolling. Chrome’s 2019 article on wheel listeners explains that an observation-only listener can be registered as passive: {passive: true} tells the browser that the handler will not call preventDefault(), so it need not wait for possible cancellation. This is a performance principle, not evidence that every slow scroll is caused by a wheel handler.
Chrome introduced a passive-by-default change for certain root-target wheel listeners in Chrome 73. Its article reports historical measurements from 2019: 75% of wheel and mousewheel listeners on root targets did not specify a passive option; more than 98% of those listeners did not call preventDefault(); and the article estimated that fewer than 0.3% of pages might experience unintended scrolling or zooming from the change. Those figures describe that historical Chrome intervention, not how common scrolling failures are today or how all browsers behave. See Chrome’s wheel-scrolling explanation and its touch-scrolling guidance.
Rank #2
Another scroll area may be receiving the gesture
Pages often have independently scrollable regions: a modal, drawer, chat panel, embedded iframe, or element with its own scrolling. The gesture may be over that region rather than the document. If it has reached its top or bottom boundary, the next movement may stop there or pass to a parent container. That transfer, called scroll handoff in Firefox’s technical documentation, can make the page seem frozen or cause the content behind a dialog to move. Firefox’s asynchronous panning documentation describes iframe hit testing and scroll handoff; Chrome’s scroll-chaining guide explains boundary behavior for nested areas.
A busy page or a browser setup can feel like a lock
JavaScript that keeps the main thread busy can make a page sluggish, even when scrolling is not explicitly disabled. Input methods can behave differently: a keyboard test does not establish that touch panning works, and a mouse-wheel test does not prove a touchpad or phone will work. Extensions, blocked resources, cached site data, and browser settings can also change how a page behaves. Compare one variable at a time so the result stays useful.
For site owners: inspect the actual scroll target
Reproduce the failure on the affected browser and device, then determine which element is supposed to move: the document, an app wrapper, a modal, an iframe, or another nested region. Do not assume the document is the target just because the page looks like one continuous surface.
- Inspect the target and its ancestors for constrained heights and
overflow: hiddenor other overflow rules that prevent the intended element from scrolling. - Check whether opening a dialog applies a scroll lock to
html,body, or a wrapper, and whether closing the dialog reliably removes that lock. A stale lock is a hypothesis to verify in the affected page, not a diagnosis that can be made from a report alone. - Inspect overlays, drawers, iframes, and panels for a layer intercepting input or capturing the gesture. Confirm that the area under the pointer or touch is the area the user can actually scroll.
- Search for global
wheel,mousewheel,touchstart,touchmove, or pointer handlers that callpreventDefault(). Keep cancellation scoped to the component that needs it. - If a handler only observes an event, mark it passive when it does not need to cancel the browser’s action. Do not mark a listener passive if its intended behavior depends on
preventDefault().
Use touch and boundary CSS narrowly
touch-action declares intended touch behavior
Apply touch-action to the smallest element that needs a custom gesture, not globally. For example, Chrome gives pan-y pinch-zoom as an option for a horizontal carousel that should still allow vertical page panning and pinch zoom. Do not set touch-action: none on the whole page as a quick fix: Chrome documents that it disables browser scrolling and zooming within the element. Test on the actual affected devices; older or mobile Safari behavior may differ from the Chrome guidance.
Rank #4
overscroll-behavior controls what happens at a boundary
Use overscroll-behavior when you have decided what should happen when a nested scroll area reaches its edge—for example, keeping a dialog’s content from scrolling the page behind it. It adjusts scroll chaining and overscroll behavior; it does not restore scrolling if the main content is accidentally locked. Check the whole interaction: scrolling within the panel, reaching its boundary, and continuing the gesture outside it.
Test the fix across inputs and browsers
Use a small reproduction matrix rather than relying on one successful test. Record the browser and device, input method, scroll target, and symptom. Test the page on each relevant combination with the same overlay state and content. A successful wheel test does not establish that touch panning is correct, and keyboard behavior may differ on a page whose main thread is busy.
Recommended Free Tools
| Observation | Next check |
|---|---|
| Only the mouse wheel fails | Compare touchpad, keyboard, and scrollbar; inspect wheel handlers and input/browser settings. |
| Touch fails but wheel works | Inspect touch listeners and touch-action on the affected element; test on the affected device. |
| A modal or panel fails at its edge | Check which container owns the scroll and whether boundary chaining matches the intended design. |
| Background moves while a dialog is open | Inspect dialog scroll handling and background scroll lock; verify the lock is removed when the dialog closes. |
| Page is slow across input methods | Check main-thread work and whether scripts or resources are delayed or blocked. |
Or skip the browser setup
If your goal is to capture the page rather than debug its scrolling, ScreenshotNeo can return a screenshot or PDF through one GET request. It accepts the cookie or consent banner as a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and other MCP clients. The free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 shots. See ScreenshotNeo and the API documentation.
For a quick capture, replace the target URL with the page you need and use your API key:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpSign up for ScreenshotNeo to get 1,000 screenshots a month free, with no card required.
Frequently Asked Questions
Can I tell whether the site or my browser is responsible?
Compare the same page in another browser and compare another site in the affected browser. Those checks narrow the likely source, but do not prove a specific cause.
Should I disable JavaScript to fix scrolling?
Not as a general fix. JavaScript may be required for the site, and disabling it can break page functionality. Check extensions or blocked content first, and site owners should inspect event handlers.
Does a mouse-wheel test confirm that a mobile page will scroll?
No. Touch, wheel, touchpad, keyboard, and scrollbar input can follow different paths, so test the input method and device involved.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
