BeanNestTools

Browser repaint timing

Estimate the refresh cadence this browser is actually receiving.

BeanNest samples foreground requestAnimationFrame callbacks and reports a robust timing estimate. Keep this tab visible while it settles.

Runs in your browserNo display fingerprint uploadNo account needed

Refresh rate measurement workspace

Estimated refresh rate
…Hz

Warming up — collecting foreground repaint timing.

For a cleaner reading

Keep this page in the foreground.

  • • Leave the window visible while the status moves from warm-up to stable.
  • • Close heavy animation or video workloads if the value jumps unusually.
  • • Check your OS/display settings if the estimate differs from the mode you expected.
Samples
0
Sample time
0.0 s
Frame interval
—
Timing spread
—

How to use it

Read the estimate only after the timing settles.

  1. 01

    Keep the page visible

    Browsers can pause or throttle animation callbacks when a tab is hidden. BeanNest discards that interrupted sampling window instead of treating a long gap as panel timing.

  2. 02

    Wait for “Stable estimate”

    The first frames are warm-up. The tool keeps a bounded sample and uses a robust median so a few slow frames do not dominate the result.

  3. 03

    Compare with your settings

    If you expected 120 Hz or 144 Hz but consistently see something else, check the operating-system display mode, power settings, browser load, cable, and monitor configuration.

What the result means

The number is an effective browser-observed estimate.

requestAnimationFrame normally runs before a repaint, so its callback timing is useful for estimating the cadence delivered to this page. It is not a direct read of panel firmware, EDID, or a laboratory refresh-rate sensor.

Browser and system behavior can change the reading.

Compositor scheduling, CPU/GPU load, power saving, multiple monitors, variable-refresh behavior, and background throttling can all affect the callback sequence. Timing spread is shown as context rather than turned into a fake hardware score.

The timing data stays local.

BeanNest does not send measured Hz, frame intervals, sample timestamps, timing spread, display dimensions, or a monitor identity to analytics. The sample disappears when you reload or close the page.

Why does the number move at first?

The tool intentionally warms up and collects enough visible frames before calling the estimate stable. Early callback timing is more easily affected by page startup and scheduling noise.

Why is my result lower than the monitor's advertised Hz?

Check the active operating-system display mode first. Then consider browser workload, power settings, multi-monitor composition, cable/input limitations, and whether the panel is currently using a different mode.

Can this prove an exact hardware refresh rate?

No. It estimates the repaint cadence presented to this foreground browser page. Hardware certification requires information and measurement outside the normal web-page sandbox.

What happens when I switch tabs?

The current sample is invalidated. When the page becomes visible again BeanNest starts a fresh warm-up window so the hidden-tab pause is not reported as display timing.

Keep checking

More display and device checks

Dead Pixel Test

Cycle solid screen colors to visually check for pixels that stay dark, bright, or different.

Open tool →

Touch Screen Test

Check browser-observed touchscreen coverage, edges, drag continuity, and simultaneous touch contacts.

Open tool →

Sound Test

Test left and right speaker output, microphone input level, and a short local recording without uploading audio.

Open tool →