Skip to main content

Refresh rate test

Measure your display refresh rate, frame times, and motion blur

Free & unlimitedWorks offline

Speed presets

Detected refresh rate

HzFrame time: — ms

Motion test

Frame time graphLast 120 frames

Motion blur test

Controls

Statistics

Current Hz
Avg frame time
0 ms
Min / max
0 / 0 ms
1% low
0 Hz
Dropped frames
0
Jitter
0.00 ms

Refresh rate tips

  • Close other browser tabs and applications for the most accurate measurement
  • The detected Hz should match your monitor's advertised refresh rate (60, 120, 144, 240 Hz)
  • If detected Hz is lower than expected, check that your OS display settings are configured correctly
  • High dropped frame counts may indicate background processes competing for GPU resources
  • VRR (G-Sync/FreeSync) monitors may show variable frame times; this is normal behavior

About refresh rate testing

How detection works

The test measures time between requestAnimationFrame callbacks over 60+ frames. This correlates directly to your display's actual refresh rate.

1% low explained

The 1% low value represents the Hz equivalent of the worst 1% of frame times. Low values indicate frame pacing issues or stuttering.

All processing happens in your browser. No data is sent to any server.

This refresh rate test times the gaps between requestAnimationFrame callbacks and averages them over 60 frames, which is the closest a web page can get to reading your display's actual refresh rate. Alongside the Hz figure it reports mean frame time in milliseconds, the minimum and maximum over a rolling 120-frame window, a 1% low expressed in Hz, a dropped-frame count and a jitter figure. Four lanes of balls travel at 960, 720, 480 and 240 pixels per second so you can see what the number looks like, a scrolling text strip tests motion blur readability, and a frame-time chart plots your samples against 60, 120, 144 and 240 Hz reference lines.

Key facts about Refresh rate test

Key facts about Refresh rate test
Measurement methodtime between requestAnimationFrame callbacks, averaged over 60 frames
Precision shownHz to one decimal, frame time to two decimals
Rolling window120 frame times kept for the min, max, 1% low and chart
1% lowthe Hz equivalent of the 99th-percentile slowest frame time in the window
Dropped frame rulea frame whose time exceeds twice the rolling average is counted as dropped
Jitterslowest minus fastest frame time in the window; under 4 ms is graded good
Motion lanesfour rows at 960, 720, 480 and 240 pixels per second
Speed presetsSlow motion 0.5x, Normal 1x, Fast 2x, Extreme 3x multipliers on those speeds
Backgroundsdark, medium and light, to change the contrast ghosting is judged against
Chart references60 Hz at 16.67 ms, 120 at 8.33 ms, 144 at 6.94 ms, 240 at 4.17 ms
Snapshotscapture the current Hz, frame time and stats to compare settings side by side
ExportJSON with the detected Hz, frame time, statistics and every snapshot taken
Flashing-content warningshown once before the animation starts, as the fast lanes strobe at high contrast

What happens to your file

The whole measurement is a loop inside this tab. requestAnimationFrame gives the page a timestamp on each frame, the differences are kept in a fixed 120-entry array, and the balls, text strip and chart are painted on canvas elements in the same tab. Nothing is uploaded, no result is stored between visits, and the JSON export is produced locally as a Blob and handed to your browser as a download. The only value written outside memory is a sessionStorage flag remembering that you acknowledged the flashing-content warning, and it is discarded when the tab closes. Because the loop is driven by the browser's own frame scheduling, it also stops measuring the moment the tab is hidden — which is the one thing to know before you trust a number you read after switching windows.

About this tool

  1. 1

    Let it settle before reading

    The Hz figure updates once every 60 frames. Give it five to ten seconds after the page loads so the first, slower frames during startup drop out of the average.

  2. 2

    Close what you can

    Other tabs, video calls, recording software and a busy GPU all steal frames. Close them before recording a figure you intend to compare with anything.

  3. 3

    Go fullscreen

    Fullscreen removes browser chrome and compositor overhead and usually produces the cleanest reading. Escape returns to the normal view.

  4. 4

    Compare Hz to your display setting

    The detected value should match what your operating system's display settings report — 59.9, 120, 143.9 or 239.8 are normal readings for 60, 120, 144 and 240 Hz panels.

  5. 5

    Read the frame-time stats, not just Hz

    Average frame time tells you the same thing as Hz. The min, max and 1% low tell you whether frames are arriving evenly, which is what stutter actually is.

  6. 6

    Watch the four motion lanes

    Set the background that matches the content you care about and follow one ball with your eyes. At 60 Hz the 960 px/s lane visibly steps; at 144 Hz and above it stays a solid shape.

  7. 7

    Take snapshots to compare

    Change one thing — a different refresh setting, fullscreen versus windowed, another browser — and take a snapshot each time. The list keeps the Hz and frame time for each so you can compare them directly.

Specs & compatibility
Browser supportany browser with requestAnimationFrame — Chrome, Edge, Firefox, Safari and Opera
Timer resolutionframe timestamps are coarsened for security, so single-frame values are noisier than the 60-frame average
Background tabsbrowsers throttle animation frames to roughly 1 Hz when the tab is not visible
Variable refreshwith G-Sync or FreeSync active the browser may render below panel maximum, so the figure reads low
Multi-monitorreports the display the browser window is on; drag the window across to test the other screen
macOS ProMotionreads 120 Hz only while the content is animating; it can drop to 60 or lower when idle
Maximum readablelimited by what the browser will schedule — 360 Hz and 500 Hz panels may report lower
Account or installnone — no signup, no extension
  • A reading of 59.94 rather than 60 is normal; broadcast-derived timings are not exactly round numbers and neither are panel clocks.
  • If a 144 Hz monitor reports 60, check the operating system display settings first — Windows often reverts to 60 Hz after a driver update or a cable change.
  • A DisplayPort cable or a certified high-speed HDMI cable is usually required above 120 Hz at high resolutions; an old cable is a common cause of a capped reading.
  • Laptops on battery frequently drop the panel to 60 Hz to save power; plug in before testing.
  • With variable refresh enabled, the browser may only render as fast as it needs to, so a low reading here does not prove the panel cannot go higher.
  • Jitter and the 1% low matter more than the headline number: a steady 120 Hz looks better than a 165 Hz average with regular spikes.
  • Test each monitor separately by dragging the browser window onto it — the page can only measure the display it is being composited on.
  • Use Slow motion 0.5x when judging ghosting and Extreme 3x when judging whether the panel keeps up with fast camera pans.
  • Refresh rate detected from requestAnimationFrame timing, to one decimal
  • Frame time average, min, max, 1% low and jitter
  • Dropped-frame counter using a two-times-average rule
  • Four motion lanes at 240 to 960 pixels per second
  • Speed presets from 0.5x slow motion to 3x extreme
  • Frame-time chart with 60, 120, 144 and 240 Hz reference lines
  • Hz snapshots and JSON export
  • Confirming a new 144 Hz or 240 Hz monitor is actually running at its rated refresh rate rather than 60.
  • Checking whether a cable or port change fixed a capped refresh rate.
  • Seeing the practical difference between 60 Hz and 144 Hz motion before buying a monitor.
  • Diagnosing stutter by watching the 1% low and dropped-frame counters rather than the average.
  • Verifying that a laptop keeps its high refresh rate on battery.
  • Comparing how two browsers schedule frames on the same machine.
In order of likelihood: the operating system is still set to 60 Hz, the cable or port cannot carry 144 Hz at your resolution, the laptop is on battery and has dropped the panel to save power, or the browser window is on a second, slower monitor. Check the display settings first, then the cable. If the settings say 144 and this page says 60, drag the window onto the other screen to rule out a multi-monitor mix-up, and try fullscreen to remove compositor overhead.
Accurate enough to distinguish 60, 120, 144, 165 and 240 Hz reliably, and accurate enough to spot dropped frames. It is not a laboratory instrument. Browsers deliberately coarsen high-resolution timestamps to limit side-channel attacks, and the page only sees when the browser called it, not when the panel finished scanning. That is why the tool averages 60 frames before printing a number, and why a fraction of a hertz either way is noise rather than a finding.
The tool keeps the last 120 frame times, sorts them, takes the one at the 99th percentile — effectively the slowest frame in the window — and converts that millisecond value to a hertz figure. If your average is 144 Hz but the 1% low is 48 Hz, one frame in that window took three times as long as it should have. That is exactly what you perceive as a hitch. A healthy system shows a 1% low close to the average; a large gap means frame pacing problems somewhere in the browser, the GPU or the driver.
It changes what the measurement means. With variable refresh active, the display follows the application rather than the other way round, so if the browser only needs to render at 100 frames per second, the panel runs at 100 Hz and this page correctly reports 100. That is not a fault. To measure the panel's maximum rate, either disable adaptive sync for the test or run the animation fullscreen at the Extreme speed preset so the browser has a reason to render as fast as it can.
Because requestAnimationFrame is scheduled by the browser's compositor, and a browser rendering a web page will not necessarily present a new frame on every panel refresh at very high rates. On some platforms the callback is capped well below the panel's maximum. If the reading sits at a suspiciously round lower value on a very fast panel, that ceiling is usually the browser or the compositor, not the display. Vendor tools or a high-speed camera are the honest answer above roughly 240 Hz.
Browsers throttle requestAnimationFrame in tabs that are not visible, often to about one callback per second, to save battery and CPU. The measurement loop therefore starves, and any value you read immediately after returning includes those throttled frames. Keep the tab in the foreground for the whole measurement, give it a few seconds to flush the rolling window after you come back, and ignore any dropped-frame count that accumulated while you were away.
View all

Part of Hardware testers that run in your browser

Updated

We use anonymous analytics to improve ToolChamp. No personal data is stored or sold. Privacy Policy