Screen Refresh Rate (Hz) Test
Instantly check your screen's real-time refresh rate (FPS). Verify if 120Hz, 144Hz, or 240Hz high refresh modes are active and check for smooth motion.
Avoids unrelated permissions and runs in your browser with the device APIs available on this device.
Works best in current Chrome, Edge, Safari, and Firefox. Support depends on requestAnimationFrame() timing, secure HTTPS, hardware availability, and browser policy.
Refreshrate.tipsTitle
Hz Guide
Use animation loop to estimate rAF interval / FPS.
Take baseline measurements first (animation)
Run for 10 seconds to confirm whether the refresh rate is high and overall stability.
Compare the static mode (to see if the brush is reduced)
Static content is more likely to trigger the system power saving/dynamic refresh strategy and is suitable for judging "whether it will drop to 60/30".
Pressure control (to see if the load is brushed)
When the CPU/GPU is under greater pressure, will frame drops, increased jitter, and refresh rate decrease occur?
What this tool checks
This page checks whether the browser can present frames at the screen cadence you expect and whether that cadence stays stable.
frame cadence
Measures how often the browser is being allowed to render frames on the current display path.
estimated refresh rate
Helps estimate whether the result is closer to 60Hz, 120Hz, 144Hz, 240Hz, or another mode.
stability over time
Useful for spotting whether the reported cadence stays consistent or drifts under load.
spike detection
Makes sudden frame-time jumps and unstable pacing easier to notice.
window vs fullscreen comparison
Lets you compare whether the browser behaves differently in fullscreen mode.
power-saving clues
Can reveal when battery or display policies are limiting frame delivery.
What this tool cannot confirm
This is a browser-side estimate of display cadence, not a hardware oscilloscope measurement of the panel itself.
not a panel certification
It cannot formally certify the exact native panel refresh rate or every VRR behavior.
browser timing is still an estimate
The result depends on requestAnimationFrame timing and can be influenced by browser scheduling.
background tabs are throttled
Minimized windows, background tabs, or energy-saving states can heavily distort the reading.
VRR can change the story
Adaptive sync and dynamic refresh can make the result fluctuate instead of staying on one exact number.
How the result is generated
The result is generated from browser frame-timing observations, mainly requestAnimationFrame cadence and its stability over the sample period.
animation timing start
The page begins measuring successive browser animation frames.
frame interval sampling
Frame-to-frame timing intervals are collected over a rolling time window.
cadence estimation
The page estimates the effective refresh rate from the observed timing pattern.
stability analysis
Spikes and jitter are tracked to show whether pacing is consistent.
local result display
The browser displays the estimated rate and pacing quality seen during this session.
Interpret your results
Use the estimate to tell whether the browser is actually seeing a high-refresh experience, not just whether the monitor claims to support it.
| Observed timing result | Likely meaning |
|---|---|
| Around 60Hz | The browser is effectively running in a standard refresh path or is being capped there. |
| Lower than expected | Power saving, cable / adapter limits, OS display settings, or browser caps are reducing cadence. |
| Highly unstable reading | Heavy system load, browser scheduling noise, or VRR behavior is affecting the estimate. |
| Higher in fullscreen | The system may allow better refresh behavior in fullscreen than in a normal window. |
| Consistently near the target rate | The browser is successfully presenting near the expected high-refresh mode. |
Supported browsers and known limitations
Refresh-rate estimation depends on browser scheduling behavior as much as on the actual display mode.
| browser | timing exposure | high-refresh detection | fullscreen comparison | known limitations |
|---|---|---|---|---|
| Chrome | Good | Good | Good | Extensions and load can still distort the estimate. |
| Edge | Good | Good | Good | Windows display policy and power mode strongly affect the outcome. |
| Firefox | Good | Good | Good | Timing behavior may differ slightly from Chromium browsers. |
| Safari | Good on supported platforms | Good | Good | macOS and iOS display behavior can be highly platform-specific. |
| iOS Safari | Basic to good | Basic to good | Good | Mobile power management can change rates quickly. |
| Android Chrome | Good on supported devices | Basic to good | Basic to good | Vendor display modes and battery saving can affect readings. |
Use cases
This test is most useful when you need to confirm that browser motion really feels high-refresh on the current setup.
after enabling 120Hz or 144Hz
Check whether the browser actually sees the higher refresh cadence.
after connecting a new monitor
Confirm that the external display path is not capping the browser at a lower rate.
when motion feels less smooth
Use the test to spot whether refresh cadence dropped after a settings or power change.
when comparing browsers
See whether one browser tracks the expected high-refresh mode more consistently.
after switching battery modes
Verify whether power saving reduced the effective refresh experience.
FAQ
Frequently asked questions about refresh rate, dynamic refresh and stability judgment.
What is the measured "refresh rate" of this page?
What is measured here is the browser's requestAnimationFrame (rAF) callback rhythm, which is usually strongly related to the screen refresh rate. It reflects the output frequency of the browser's compositing/rendering pipeline and is not equivalent to the monitor panel's "nominal Hz".
How to judge whether it is high refresh rate (90/120/144Hz)?
Run in "Animation" mode for about 10 seconds to see if the "most likely refresh rate" falls stably at 90/120/144 and other gears; also observe whether the "frame interval distribution" is mainly concentrated in one cluster (for example, 120Hz).
Why does it change from 120Hz to 60Hz/30Hz in static mode?
This is a common system power saving/dynamic refresh strategy: reduce the refresh rate when content is stationary to save energy. Different operating systems, browsers, and display (internal screen/external) strategies vary greatly; comparing "animated" and "static" results is the most intuitive method.
What does "dynamic refresh possibility" mean?
When two or more high-proportion frame interval clusters appear within the statistics window (such as 60Hz and 120Hz), it usually indicates that the refresh rate is switching: it may be VRR/adaptive refresh, or it may be load fluctuations that cause the browser to only intermittently reach high refresh rates.
How do you understand "stable/slight fluctuation/unstable"?
It makes an empirical judgment based on the quantile jitter (P90-P10) and standard deviation (std) of the frame interval: the more stable it is, the more concentrated the frame interval is and the subjective smoothness is smoother; the instability may be due to dropped frames, system refresh, excessive background load, or browser frequency limitation.
Why does the result become worse after switching to the background?
The browser actively downclocks or even pauses rAF in the background to save energy and protect resources, so the measured "refresh rate" will drop significantly. This tool will automatically stop when it detects switching to the background. It is recommended to always test in the foreground.
Can this tool accurately differentiate between VRR and performance drops?
It cannot be completely precise. Both will show that the frame interval distribution becomes "more clustered/more scattered". It is recommended that you use a comparison method: switch between "Static" and "Animation", and then use "Stress" mode to verify the load impact; if the stress mode is obviously worse, it is usually more of a performance bottleneck.
Related guides
Read a few practical guides for setup, browser compatibility, and troubleshooting around this test.
Feedback / report a bug
Tell us your browser, device, and what happened.
Did this result look wrong?
Comments(0)