DeskTest.net
GitHub

Refresh Rate Test Guide

A reference for the DeskTest.net Refresh Rate Test. Explains how a browser can measure the refresh rate at all, what the number really represents, how to read the verdict, and how to fix a high-refresh panel that Windows or the driver left running at 60Hz. Read this before you conclude a monitor is broken - most "slow" panels just need one setting changed.

Open the Refresh Rate Test →

What does the Refresh Rate Test measure?

Your monitor redraws the screen a fixed number of times per second - its refresh rate, in hertz (Hz). A 144Hz panel redraws 144 times a second; a plain office monitor does 60. Higher rates make motion, scrolling, and mouse movement look smoother. The catch: buying a high-refresh monitor is not enough. Windows, macOS, the graphics driver, the cable, and even the power plan all have to cooperate, and any one of them can silently leave a 144Hz or 165Hz panel running at 60Hz.

The browser has no API that reports the refresh rate the driver set. What it does have is requestAnimationFrame (rAF): a callback the browser fires once per painted frame, in step with the display's refresh. This test times those callbacks. It runs an rAF loop for about four seconds, records the timestamp of every frame with performance.now(), discards a short warm-up, then takes the median gap between frames. Median (not average) is used on purpose: it ignores the occasional hiccup and returns the rate the display actually held. Hertz is then simply 1000 / median-milliseconds. A steady 6.94ms per frame is 144Hz; 16.67ms is 60Hz.

The tool then snaps that raw number to the nearest standard rate (60, 75, 90, 120, 144, 165, or 240Hz) and reports both the measured value and the standard it matches, plus a jank figure - how many frames landed off the expected beat.

The honest version: this measures the frame cadence the browser receives from the display - the effective refresh rate for anything drawn on screen. It is not a value read from the graphics driver, and it can be capped below the panel's true rate by the browser or by system load. It is the real, felt rate; it is not a driver readout.

What it cannot tell you

When should I run this?

Reading the results

Two steps run in order, each with a status badge: Pending (gray), Running (yellow), Pass (green), Partial (yellow), or Fail (red).

  1. Sample the animation cadence. The four-second measurement. A live bar glides across the box so you can see the smoothness with your own eyes while the numbers update. This step fails if the tab was ever in the background or if too few frames were captured to be reliable.
  2. Measured rate and jank. The median-derived Hz, the nearest standard, and the frame-time variance. It passes when the reading cleanly matches a standard with smooth cadence, and goes Partial when the rate does not match a standard or when motion is stuttering.

The verdict panel at the top gives the headline - for example "Running at 144 Hz" - with a likely cause and a recommended next step. If the measured rate is 60 or 75Hz and you know the panel is rated higher, the fix block under step 2 walks through raising it.

Copy Diagnostic Report copies a plain-text summary (frame counts, median frame time, measured Hz, matched standard, jank, browser user-agent, timestamp) for a ticket or email. Send to your IT drops the same text into a mail draft. Nothing is uploaded; the report is built in this tab.

Common results and fixes

Measured 60Hz (or 75Hz) on a monitor rated higher

The classic case. The panel can do 144Hz; the OS left it at 60. Fix the setting:

  1. Windows. Settings, System, Display, Advanced display. Under "Choose a refresh rate," pick the panel's rated value. If the high rate is not listed, the cable or port cannot carry it (see below).
  2. macOS. System Settings, Displays. Hold Option and click "Scaled" to reveal the refresh-rate list, then choose the higher rate.
  3. Check the cable and port. HDMI 1.4 caps 1080p at 120Hz and 1440p at about 75Hz. For 144Hz+ at 1440p or 4K, use DisplayPort, or HDMI 2.0/2.1. A cheap or long HDMI cable can also force a fallback. Reseat both ends, or swap the cable, and re-test.
  4. Through a dock or KVM? Many docks and KVMs cap refresh or resolution. Connect the monitor straight to the GPU to confirm, then check the dock's spec.
  5. Multiple monitors. Mixing refresh rates or running high resolution on limited bandwidth can force the driver to drop one display to 60Hz. Set each display's rate individually.

Measured a rate that does not match a standard

The reading sits between the usual standards (say 82Hz or 51Hz) and is outside the snap tolerance. Usual causes:

  1. The browser is capping frames. A browser frame-rate limiter, a battery saver, or an integrated-GPU fallback can hold rAF below the panel rate. Compare against a second browser; if it reads the standard rate, the first browser was the limit.
  2. Variable refresh (G-Sync / FreeSync). With adaptive sync on and little on screen to drive frames, the effective rate floats. This is expected behavior, not a fault.
  3. Power throttling. On a laptop, an unplugged or power-saver profile throttles the GPU and drops the rate. Plug in, choose high performance, and re-test.
  4. System load. Heavy background work steals frame time. Close other apps and tabs and run it again with nothing else animating.

Around the right rate, but motion is stuttering

The average rate is close to a standard, but frame times are uneven - frames arrive late or get dropped. The average can look fine while the experience feels rough.

  1. Background load. Close heavy apps and browser tabs (video calls, big spreadsheets, other animations) and re-test.
  2. Extensions. Ad blockers with large filter lists, screen recorders, and injected scripts run on every page and can steal frame time. Test in a private/incognito window with extensions off.
  3. Graphics driver. Stutter that started after a Windows update is often a driver that needs a clean reinstall. Update from NVIDIA, AMD, or Intel directly.
  4. Battery / thermals. On a laptop, plug in and make sure the machine is not thermally throttling; sustained heat causes periodic frame drops.

Measurement invalid - tab was in the background

Not a hardware fault. The tab lost focus while sampling, and browsers throttle animation frames for hidden tabs, so the timing was useless. Bring this tab fully to the front, do not switch away, minimize, or click another window, and run it again. The whole measurement is four seconds.

Not enough frames to measure

The sampler captured too few frames for a reliable median. The machine was likely under heavy load, or the tab was throttled. Close other heavy apps and tabs, keep the tab in front, and re-run.

For IT admins

Refresh-rate defaults are a recurring, easy-to-miss support issue, especially after imaging or a driver push. Document the per-OS path so the helpdesk does not relearn it each call.

Windows. Refresh rate lives in Settings, System, Display, Advanced display, "Choose a refresh rate," per output. The value can revert after a cumulative update or a GPU driver reinstall. If the desired rate is missing, the limit is the cable, the port, or the driver - not the panel. For fleets, note that a Windows feature update can reset the rate; add a post-update check to your validation script or have users run this test.

macOS. System Settings, Displays; hold Option and click Scaled to expose the refresh-rate list per display. Managed Macs can pin display settings via MDM configuration profiles.

Bandwidth math the helpdesk should know. A rate that "won't appear" is almost always a bandwidth limit:

ConnectionRough ceiling
HDMI 1.41080p at 120Hz, 1440p at 75Hz, 4K at 30Hz
HDMI 2.01080p at 240Hz, 1440p at 144Hz, 4K at 60Hz
HDMI 2.11440p at 240Hz, 4K at 120Hz
DisplayPort 1.21080p at 240Hz, 1440p at 165Hz, 4K at 60Hz
DisplayPort 1.41440p at 240Hz, 4K at 120Hz (with DSC)

Docking stations, USB-C alt-mode, and KVM switches often sit below these ceilings; when a rate is missing, test with a direct GPU-to-monitor cable to isolate the dock.

Behind the scenes

The measurement is a single requestAnimationFrame loop. Each callback pushes performance.now() onto an array; the loop stops after about four seconds or a hard frame cap. The first 500ms are discarded so the browser's first slow frames and any layout settle do not skew the result. The remaining timestamps are differenced into inter-frame intervals, and the median interval becomes the rate: Hz = 1000 / medianMs. Median resists outliers, so one long frame from a background garbage-collection pause does not drag the number down the way a mean would.

Jank is measured two ways: the share of intervals more than 25% off the median (off-cadence frames), and the count of intervals longer than 1.5x the median (dropped display frames). Low variance reads as smooth; high variance is flagged even when the average rate is fine.

The moving bar is driven by the same rAF loop, positioned each frame from the elapsed time as a triangle wave, so what you watch is the cadence being timed - a visibly stuttering bar means a stuttering measurement. Page visibility is watched with the visibilitychange event; if the tab is hidden at any point, the run is marked invalid rather than reported, because hidden-tab rAF throttling would otherwise produce a fake low number.

Everything - the timestamps, the math, and the report - stays in this browser tab. The page makes no network requests. View source to confirm.

Elsewhere on the web: