Refresh rate test for browser-observed Hz.

How this test works

The test samples animation callbacks after a warm-up and reports a stable estimate when possible.

1. Prepare the display using the checklist below.
2. Select Start test and allow fullscreen mode if your browser asks.
3. Use the arrow keys, on-screen controls, or click the pattern to move through the test.
4. Exit the runner and save a local observation if useful.

Before you begin

• Move this window to the display you want to test
• Close heavy tabs and apps
• Keep the page visible during measurement

What to look for

• Estimated browser refresh cadence
• Median frame time
• Warnings for unstable or interrupted samples

What the browser cadence estimate represents

This page samples requestAnimationFrame callbacks after a warm-up period and reports an estimate when the timing is sufficiently stable. It also exposes median frame time and warnings when samples were interrupted or irregular. The browser schedules these callbacks; it is not reading an electrical signal from the panel. A result near 60, 120, or 144 Hz can be consistent with the active display mode, but it is not a direct physical refresh measurement or a guarantee that every application will update at that rate.

Keep this tab visible, leave the window on the monitor being checked, and avoid moving it between screens while measuring. Close heavy tabs or applications if the result is unstable. Background tabs may be throttled, power-saving settings can affect scheduling, and variable refresh behavior may change cadence. A 59.94-ish result can reflect a common timing mode or ordinary sampling variation rather than a fault. Read the confidence warning as part of the result rather than ignoring it and repeating until you see a preferred number.

Check configuration when the value surprises you

If a high-refresh monitor repeatedly looks close to 60 Hz, inspect the operating system’s display settings and the monitor’s on-screen menu. Confirm the intended mode is selected for the correct display, then review the input port and cable against the maker’s supported combinations. Browser timing is one clue in that investigation, not a replacement for system configuration. In a multi-monitor setup, make sure the test window is wholly on the target screen and restart sampling after moving it.

If the estimate varies from run to run, observe whether the tab was hidden, another window covered it, an animation was interrupted, or the computer was under load. Do not equate a momentary low callback rate with the panel losing its rated refresh capability. Conversely, an apparently stable browser estimate does not prove the monitor scans every pixel at that exact frequency under every condition. For physical timing verification, appropriate external measurement is needed.

Keep refresh rate separate from motion clarity

Refresh cadence describes how often new frames may be presented; it does not by itself tell you how quickly pixels transition or how clear moving objects appear. If you see trails, use the ghosting or response-pattern page at the same display mode. If you see a horizontal split during a game, browser composition may hide that phenomenon, so the screen tearing test has a narrower visual role. Frame rate generated by an app and refresh rate selected for an output are also different concepts, even when their numbers sometimes match.

Record the estimated cadence, stability warning, median frame time, display mode, browser, power setting, and whether the window was visible throughout. Compare repeat runs under unchanged conditions before changing configuration. This page gives a useful browser-observed signal and an honest low-confidence state; it does not certify a panel’s marketing specification. A result that differs from expectations is a prompt to check system settings and the complete signal path, not an automatic hardware diagnosis.

Frequently asked questions