People reach for a web clock when they want a second opinion, and then immediately wonder whether the second opinion is any good. Browser clock accuracy is an easy thing to worry about and a surprisingly simple thing to reason about, because a browser does not keep time at all. It asks the operating system, formats the answer and paints it on screen. Everything that makes a web clock right or wrong happens below the browser, in layers the page has no access to.

This article explains what a browser clock depends on, how far a device can drift when nothing is correcting it, how to check your own machine in under a minute, and which problems a web page simply cannot fix. The live clock is a reasonable place to run those checks, since it shows milliseconds rather than rounding to the nearest second.

What Does Browser Clock Accuracy Actually Depend On?

Browser clock accuracy depends entirely on the system clock of the device you are using. The page calls Date.now(), receives the operating system's current estimate of the time, and displays it. There is no separate web time source and no correction applied in between.

That estimate has its own supply chain. The operating system periodically consults a time server using the Network Time Protocol, which traces back through NTP stratum levels to atomic clocks held at national laboratories. Between those consultations, the machine keeps time using a quartz crystal oscillator, counting its vibrations and converting them to seconds. A browser clock therefore sits at the end of a chain it neither controls nor sees, and its accuracy is the accuracy of whatever arrived at the bottom of that chain.

How Far Can A Browser Clock Drift Without NTP?

Without network synchronisation, a typical computer gains or loses a few seconds a day. Consumer quartz oscillators are usually specified in the region of tens of parts per million, and fifty parts per million alone works out at roughly four seconds a day, or two minutes over a month.

Temperature makes it worse. A quartz crystal oscillator runs at a slightly different rate when it is hot, so a laptop in a warm room drifts differently from the same laptop on a cold desk, and the error is not a constant you can subtract. This is why clock drift is corrected rather than predicted. A machine that checks in with an NTP server regularly is normally within a few milliseconds of true time; a machine that has been offline for a fortnight, or whose time service is switched off, can be several seconds out with no outward sign. The browser clock will report that error to three decimal places, which is precision without accuracy.

How Do You Check Browser Clock Accuracy?

Compare your screen against a reference you trust and watch the seconds roll over rather than reading a static number. Open a precision seconds counter next to a radio time signal, a phone on network time, or a second machine you know is synced, and look at when the digit changes.

Watching the roll-over matters because a single glance at a browser clock cannot distinguish one that is 0.1 seconds out from one that is 0.9 seconds out. Both will read the same number for most of the second. Some practical points when comparing:

  • Use a phone on network time as the reference: mobile networks and mobile operating systems sync aggressively, so a phone is usually closer to true time than a desktop.
  • Discount your own reaction time: a human cannot judge much better than about a tenth of a second by eye, so treat small differences as noise.
  • Ignore network latency: the page is reading your local clock, so a slow connection does not make the displayed time late.
  • Check after sleep and travel: resuming from suspend and crossing time zones are the two events most likely to leave a machine displaying the wrong time.

What A Web Page Cannot Fix

A web page cannot correct a wrong system clock, and it should not pretend to. JavaScript has no permission to set the operating system time, and any page that quietly offset its display to match a server would be showing you something your own calendar, file timestamps and login sessions all disagree with.

There are further limits worth knowing, and they set a ceiling on browser clock accuracy that no amount of code will lift. The system clock can step forwards or backwards at any moment when a synchronisation correction lands, so wall-clock time is unsafe for measuring durations. Browsers deliberately reduce the resolution of their timers as a defence against side-channel attacks, so even performance.now() is coarsened rather than reporting raw nanoseconds. Hidden tabs have their timers throttled to roughly one callback a second, and sometimes far less, which is why a background stopwatch can fall behind. These trade-offs are examined in millisecond precision in the browser.

Precision Is Not The Same As Accuracy

Precision is how finely a value is reported; accuracy is how close it is to the truth. A browser clock showing three decimal places is precise, and it is accurate only if the system beneath it is correct.

The distinction has a practical consequence. Date.now() gives you wall-clock time, which is accurate when synced but liable to jump. performance.now() gives you monotonic time, which never runs backwards and never jumps, but counts from the moment the page loaded rather than from any calendar epoch. Use the first to answer what time it is, and the second to answer how long something took. Confusing them produces negative durations after a time correction, which is a classic and thoroughly avoidable bug.

Improving Browser Clock Accuracy On Your Own Machine

The fix is always at the operating system level, and it takes a minute.

  1. Turn on automatic time: enable the setting to set the date and time automatically, which is what activates NTP synchronisation.
  2. Check the time zone separately: a machine can hold the correct instant and still display the wrong local time if the zone is wrong.
  3. Force a sync after downtime: a device that has been off, suspended or offline for a long period should be resynchronised before it is trusted.
  4. Keep signage and kiosk machines online: an unattended screen has nobody to notice it slipping, so scheduled synchronisation matters more there than on a laptop.

Once the device is right, the browser clock is right, and it stays right for as long as the synchronisation keeps running. The background to that process is covered in NTP vs browser time, and the general idea of a continuously updating display is covered in what live time is.

Conclusion

Browser clock accuracy is not really a browser question. A web page reads the device clock through Date.now() and displays it faithfully, so a synced machine gives an accurate browser clock and an unsynced one gives a confidently wrong figure to the millisecond. Left uncorrected, ordinary quartz hardware drifts by seconds a day; with NTP running, the same machine sits within milliseconds of true time. Check the roll-over against a trusted reference, enable automatic time, and the question answers itself. Compare against the live clock or explore the other displays on livetime.now.