Refresh-Rate Test
Estimate your display's refresh cadence from real browser frame timing, see the snapped standard rate with jitter analysis, and watch a smooth gliding-bar motion test. Free, private (everything runs in your browser), and flash-free.
Refresh-Rate Measurement Tool
This tool measures how often your browser presents new frames and estimates your display's refresh cadence from that. This is a browser-based estimate, not a direct hardware measurement — the web platform cannot read your panel's scaler or EDID timing directly. Results are affected by browser scheduling, OS/GPU load, variable refresh rate (VRR), mobile power saving, and which display shows this tab.
- Frame time (median)
- — ms
- Samples used
- —
- Jitter (MAD)
- — ms
- Jitter (std dev)
- — ms
Keep this tab visible while measuring — switching tabs pauses and resets the run because background tabs are throttled. For the steadiest reading, close heavy apps, plug in your laptop, and turn off variable refresh rate or battery-saver modes first. The motion test shows one smoothly gliding bar; it never flashes.
How the measurement works
Your browser repaints the page in step with your display throughrequestAnimationFrame: each callback fires once per presented frame with a high-resolution timestamp. The tool records about 120 of these timestamps (≈2 seconds at 60 Hz), then analyses the gaps between them:
- Warm-up discard — the first frames are thrown away because just-started timers are the noisiest.
- Cleanup — non-increasing or invalid timestamp pairs are dropped defensively.
- Trimmed median — the middle band of frame intervals is averaged, so one dropped or burst frame cannot drag the result.
- Standard snapping — the measured cadence is matched to the nearest standard rate within 3 Hz (59.9 Hz reads as ≈ 60 Hz).
- Jitter report — mean absolute deviation, standard deviation, and a variation coefficient describe how consistent delivery was.
Because every step works from timestamps the browser hands out — themselves subject to scheduling granularity — the final number is honestly labelled anestimate, with the raw measured value, the snapped standard, and the jitter shown side by side so you can judge its trustworthiness yourself.
Reading your results
- Estimated cadence (Hz) — 1000 ÷ median frame interval. Compare it with the snapped standard, not with marketing specs.
- Snapped standard rate — the nearest common rate (see table below) within tolerance, plus the distance Δ. No match usually means VRR is active or the run was noisy.
- Frame time (median, ms) — the time per frame: ≈16.67 ms at 60 Hz, ≈8.33 ms at 120 Hz, ≈6.94 ms at 144 Hz.
- Samples used — frames surviving warm-up and cleanup. Fewer than a handful means the run should be repeated.
- Jitter (MAD / std dev) — spread of frame intervals in milliseconds. Near zero is a rock-solid cadence; several milliseconds of MAD means visible micro-stutter during the run.
Common standard refresh rates
The tool snaps to these standard cadences:
24 Hz30 Hz48 Hz50 Hz60 Hz75 Hz90 Hz100 Hz120 Hz144 Hz165 Hz200 Hz240 Hz300 Hz360 Hz480 Hz
Limitations you should know
Variable refresh rate (VRR / adaptive-sync). G-Sync, FreeSync, ProMotion, and LTPO panels deliberately vary their cadence moment to moment. A single-number estimate cannot capture a moving target — expect drifting readings or no standard match, and disable VRR temporarily if you want the panel's ceiling rate.
Browser scheduling. Frames pass through the browser compositor, which quantises, batches, and occasionally skips work. Timer clamping, intervening layout, and garbage collection all add noise the panel itself never had.
OS and GPU load. Game downloads, video encodes, screen recording, and even an animated tab next door steal frame budget. High jitter with a correct snapped rate is the classic signature of a loaded system, not a broken display.
Mobile devices. Phones and tablets add adaptive refresh, battery-saver caps, and thermal throttling on top of everything above. Measure while awake and cool, with power saving off, and treat phone readings as especially approximate.
Multiple displays. Frame callbacks follow the vsync of the display showing the window. A 60 Hz and a 144 Hz monitor on one desk will each report their own cadence — keep the window fully on the display under test.
Tips for a stable reading
- Keep the tab visible and the device awake for the whole ~2 second run.
- Close games, editors, video calls, and screen recorders first.
- Plug in laptops and turn off battery saver / low-power mode.
- Disable VRR or set a fixed refresh rate in display settings for the test.
- Measure two or three times — agreement across runs is the real signal.
- Use the fullscreen motion test as a cross-check: visibly smooth glide corroborates a stable number.
Frequently Asked Questions
Is this my exact hardware refresh rate?
No. This is a browser-based estimate of display presentation cadence, not a direct hardware measurement. The web platform cannot read panel scaler or EDID timing directly — it samples requestAnimationFrame timestamps and infers the cadence. For the factory specification, check display settings or manufacturer specs.
Why does it show 59.9 Hz instead of exactly 60 Hz?
Browsers schedule frames with small timing variations, so a trimmed-median estimate lands slightly off the nominal rate. The tool snaps the measured cadence to the nearest standard rate within 3 Hz and reports the distance, so 59.9 Hz is presented as approximately 60 Hz with the raw value shown alongside.
What does an unstable or high-jitter result mean?
Scattered frame timing usually means variable refresh rate (VRR or adaptive-sync) is active, the browser is dropping frames under OS or GPU load, a battery-saver or thermal throttle kicked in, or the tab moved across displays. Close heavy apps, disable VRR for the test, and measure again with the tab visible.
Why do I get different results on different monitors?
requestAnimationFrame follows the vsync of whichever display currently shows the browser window, so each monitor reports its own cadence. Drag the window fully onto one display, wait a moment, and measure again to test that display specifically.
Does this work on phones and tablets?
Yes, with extra caveats. Mobile displays often use adaptive refresh (LTPO panels that slide between rates), low-power modes that cap the frame rate, and aggressive thermal throttling. Measure with the device awake, plugged in where possible, and battery saver off for the most representative reading.
Is the motion test safe? Does anything flash?
Yes, it is safe. The fullscreen motion test shows a single solid bar gliding at constant speed against a static background — nothing flashes, strobes, or auto-cycles. If your system requests reduced motion, the bar renders as one still frame instead of animating.