Refresh Rate Test

How to use

1. Move the entire browser window onto the display you want to check before starting; do not straddle two monitors.
2. Note the refresh mode selected for that display in Windows or macOS. Compare the result with that current mode, not only the monitor’s advertised maximum.
3. Close or reduce heavy tabs and background work, and keep the same browser and power state when comparing runs.
4. If you want a larger inspection surface, enter Fullscreen before Start. Fullscreen is locked while a measurement is active.
5. Choose a 3s, 5s, or 10s measurement window.
6. Keep this tab visible and focused. Do not move the window, resize it, or change display settings while it runs.
7. Click Start and let the 500 ms warm-up pass; warm-up frames are not included in the formal result.
8. Let the selected measurement window finish for a clean comparison run. Stop remains available for user control, but an early Stop produces a partial result that is not saved to history.
9. Read the robust estimate with median interval, P95, MAD, sample counts, long frames, and variable timing context.
10. Compare a full-window result with the selected OS display mode, then repeat under the same display, browser, focus, power, and duration when needed. Full-window aggregate summaries appear in Local run history.

What the result means

• The primary estimated refresh rate is 1000 ÷ the median of robust-filtered post-warm-up requestAnimationFrame intervals.
• Median interval is the typical time between browser-observed frames; 16.7 ms is near 60 Hz and 8.3 ms is near 120 Hz, without certifying the panel.
• P95 is the slower tail of the filtered interval set. MAD (median absolute deviation) shows how far intervals typically vary around their median.
• Stability is a page-derived interval-consistency indicator: 1 − (MAD ÷ median interval), clamped to 0–1. It has no universal good/bad cutoff and is not a confidence score.
• Raw post-warm-up is every retained interval. Filtered estimate samples are the values used for the robust median; excluded outliers remain represented in raw counts and timing diagnostics.
• Long frames and severe stalls are browser interval observations. They are not physical dropped-refresh counts, guaranteed panel frame skips, or game dropped frames.
• A value such as 59.94, 119.8, or 143.8 can be close to a nominal mode while still reflecting timing and scheduling variation. DeviceMetrik keeps the observed estimate instead of snapping it to a marketing label.
• Compare the estimate with the refresh mode currently selected for this display in Windows or macOS. A display capable of 240 Hz can be intentionally running at 144 Hz.
• Variable frame timing can be consistent with VRR, browser scheduling, power behavior, compositor work, or load. This page does not detect FreeSync, G-Sync, or VRR activation.
• Refresh rate describes presentation cadence; FPS describes frames an application or game produces. Use FPS Test for a browser workload, not this page’s estimate, when investigating game FPS.
• Automatic completion means the full selected 3s, 5s, or 10s measurement window finished. An early Stop freezes partial browser-timing evidence, but it did not complete the selected window and should not be treated as a clean comparison run.
• Hidden, blurred, materially resized, or fullscreen-changed runs are interrupted and should be repeated rather than compared as clean measurements.
• Local history stores only full-window aggregate summaries for comparison in this browser. Manual Stop and interrupted runs are not saved; raw frame timestamps and interval arrays are not persisted or uploaded.

Limitations

• requestAnimationFrame generally follows the display path, but this is browser- and compositor-observed timing rather than panel telemetry.
• Browsers throttle or pause animation in hidden and background tabs, so a background result does not describe the display normally.
• Browser scheduling, system load, hardware acceleration, other windows, and power-saving behavior can change frame delivery.
• Variable or dynamic refresh modes can change timing while a run is active; observed variation does not identify the underlying feature.
• With multiple displays, the page cannot automatically know which physical panel you mean. A window spanning displays can mix presentation conditions.
• Moving the window, resizing it, changing devicePixelRatio, or changing display settings can create a different measurement environment and interrupt the run.
• The result can differ across browsers, versions, operating systems, webviews, and device scheduling conditions.
• This page cannot read EDID, the monitor model, the advertised maximum, or a physical panel refresh counter.
• It cannot directly detect physical panel refreshes, prove frame skipping, or identify a faulty cable, GPU, port, dock, adapter, or monitor.
• It is not a game FPS benchmark, pixel response-time test, ghosting test, tearing diagnosis, or input-lag measurement.
• A browser estimate is evidence about this local run. It is not a hardware-health certificate or a universal pass/fail decision.

Troubleshooting

A 144, 165, or 240 Hz display reads near 60 Hz

Check the current mode for the correct display in Windows or macOS, move the whole window onto that display, keep the tab focused, and compare without power-saving changes. The browser result cannot identify which connection component is limiting delivery.

The result changes between runs

Use the same display, window placement, OS mode, browser, power state, duration, and background workload. Close heavy work, let startup settle, and repeat before changing hardware.

The value is 59.94, 119.8, or 143.8 instead of a round number

Keep the observed value. Small fractional differences can come from nominal timing and browser scheduling; compare it with the selected OS mode instead of forcing it to 60, 120, or 144.

The wrong monitor was measured

Before Start, move the entire browser window to the target display and keep it there. Run a fresh measurement for each monitor; do not compare a window straddling two displays.

The run says it was interrupted

Start again after returning to the page. Keep the tab visible and focused, do not resize or move the window, and do not change display settings during the measurement.

The result says Stopped early or partial

The browser timing collected before Stop remains visible, but the selected measurement window did not finish. Run the same duration to automatic completion before using it as a clean comparison.

The tab was hidden or the window lost focus

Browsers can throttle background animation. Reset and run again with this tab in front; an interrupted run is not saved as a normal history result.

Fullscreen was switched during a run

Use Fullscreen before Start when desired. The control is unavailable while measuring because entering or leaving fullscreen changes the viewport and invalidates the clean run.

The reading is lower on battery or in a low-power mode

Repeat with the same power state, then compare a normal-performance run if that is relevant to your question. Power behavior can change browser frame delivery without proving a panel fault.

The browser result is correct but a game is lower FPS

Refresh rate and application FPS are different measurements. Check the game’s workload, frame cap, synchronization, and performance settings; use FPS Test for a controlled browser workload.

Timing variation is large or sample count is low

Keep the page foregrounded, reduce background activity, choose a longer available window, and repeat. Treat a low-sample or highly variable run as context to investigate, not a hardware verdict.

Related tools

• FPS Test

  Measure completed browser canvas frames under light, high-load, and paced reference workloads. Compare average FPS, frame-time tails, stalls, and local runs—not a game or GPU benchmark.

• Frame Skipping Test

  Run a browser timing preflight, then photograph a discrete pattern for possible frame-skipping gaps. Review long frames, P95/P99, and stability—not a hardware verdict.

• Screen Resolution

  See browser-reported screen and viewport CSS sizes, DPR, and an estimated device-pixel size. Refresh after display changes; this is not native panel telemetry.

FAQ