Browser Clock Accuracy Explained

A live clock on screen shows 14:47:13.482. The digits update smoothly, the milliseconds flicker, and the display suggests precision down to a thousandth of a second. That suggestion is wrong. The number you see is the time as it was when the page asked the operating system for it, not the time as it is when your eye lands on it. From the system call to the screen, the value sat in a rendering pipeline for one to three screen refreshes. The clock is already old by the time you read it.

Here is what that means in practice. You open a web page with a live clock. The page calls Date.now(), receives the operating system's current estimate of the time, and paints it on screen. No separate web time source exists. No correction gets 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 hierarchy levels to atomic clocks held at national laboratories. Between those consultations, the device 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.

Where the browser gets its time

Date.now() calls the operating system's clock. No independent time source exists in the browser. JavaScript has no permission to read a GPS signal, no access to a radio time broadcast, and no way to ask a time server directly. The browser is a client of the OS clock, nothing more.

The same applies to the clock's on-screen readout. When a page shows 14:47:13.482, the fractional part comes from the same system call as the hours and minutes. It is not a separate measurement. The browser formats what the OS gave it, and the OS gave it whatever its own internal state happened to be at that instant.

Why the browser cannot fix a wrong clock

A web page cannot improve on the system clock. It cannot detect that the clock is wrong, because it has no reference to compare against. A page that shows time is a mirror. If the mirror is crooked, the reflection is crooked, and the mirror will never know.

What the OS actually does with NTP

Operating systems do not set the clock once and forget it. They run a background service that periodically contacts a time server using the Network Time Protocol. On a typical consumer device, that sync happens every 9 to 64 minutes, depending on the OS and its configuration. Between syncs, the device is on its own.

The protocol works by sending a request to a time server, measuring the round-trip delay, and computing the offset between the local clock and the server's time. The OS then gradually adjusts the local clock to remove that offset. The word "gradually" matters. NTP corrects by slewing, not jumping. A clock that is 50 thousandths of a second fast does not snap back to correct. It slows down slightly until it has lost those 50 thousandths, then returns to normal speed. This prevents sudden jumps that would confuse logs, timers, and any software that assumes time moves forward at a steady rate.

The time zone blind spot

What NTP cannot do is fix a misconfigured time zone. A device set to the wrong zone will sync its clock correctly to UTC and then show the wrong local time anyway. The OS handles time zones, and the browser simply reads the result.

How much a computer clock drifts between syncs

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. Fifty parts per million works out at roughly four seconds a day, or two minutes over a month. That is the expected error for a typical device with no time service running.

Why drift is not a fixed offset

The error is not constant. A quartz crystal oscillator runs at a slightly different rate when it is hot. A laptop in a warm room drifts differently from the same laptop on a cold desk. The error is not a constant you can subtract.

This is why clock drift is corrected rather than predicted. A device that checks in with an NTP server regularly is normally within a few thousandths of a second of true time. A device 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.

What the hardware actually delivers

Consumer quartz oscillators sit at the budget end of timekeeping. A laboratory caesium standard keeps time to within one second in millions of years. A wristwatch quartz crystal might manage fifteen seconds a month. The oscillator in a laptop or desktop motherboard is closer to the wristwatch than the laboratory, and it gets no individual calibration.

Why does a browser clock show stale time?

There is a second source of inaccuracy, and it lives inside the browser itself. The time value the page receives from the OS is correct at the instant of the system call. But the page does not paint that value to the screen instantly. The browser has a rendering pipeline. The page calculates a new time string, the layout engine decides where it goes, the compositor draws the pixels, and the screen refreshes. Each of those steps takes time, and they do not run in parallel with the clock.

Frame timing and refresh rates

The result is that what you see on screen is always slightly behind the true time. The delay is typically 16 to 50 thousandths of a second, depending on the refresh rate of your screen and the load on your device. A 60Hz screen refreshes every 16.67 thousandths of a second, so the best case is that the time you see is one frame old. Under load, it can be three frames old or more.

Why more decimal places do not mean more accuracy

This is why on-screen resolution does not equal accuracy. A clock that shows three decimal places is not accurate to the thousandth of a second. It is accurate to the thousandth at the moment of the system call, and then it sits in the rendering pipeline for several of those thousandths before you see it. The number may show 3 decimal places but be 50 to 200 thousandths behind real time due to rendering pipeline latency.

Why milliseconds on screen are not millisecond accuracy

A clock that displays 14:47:13.482 is showing you the time as it was at the instant the page called Date.now(). It is not showing you the time at the instant you read it. By the time the pixels reach your eye, the true time is later, and the difference is not visible in the readout.

The three-part gap between displayed and true time

The gap between displayed time and true time has three components. First, the system call itself takes a small but non-zero amount of time. Second, the rendering pipeline adds its 16 to 50 thousandths of a second. Third, your own perception adds a reaction-time delay if you are comparing the readout against another clock. The sum of these is usually a few hundred thousandths of a second, which is fine for a wall clock and useless for a stopwatch.

Who this actually matters for

A browser clock is a tool for humans, not for machines. A human reading a clock cannot reliably distinguish a readout that is 50 thousandths fast from one that is 50 thousandths slow. The eye simply does not sample time that finely. But a machine comparing two time sources can, and will, notice the difference.

Wall-clock time vs monotonic time in browsers

Browsers expose two distinct kinds of time to web pages, and confusing them leads to subtle bugs.

Date.now() returns wall-clock time. It is the operating system's estimate of the current date and time, expressed as milliseconds since 1 January 1970. Wall-clock time is subject to adjustment. When NTP slews the clock, when a user manually changes the time, or when daylight saving time begins and ends, wall-clock time jumps. A page that uses Date.now() to measure an interval will be wrong if the system clock changes mid-interval.

performance.now() returns monotonic time. It is a high-resolution counter that only ever increases, and it is unaffected by system clock adjustments. It resets to zero on page navigation, and it is the only correct way to measure elapsed time in a browser. Stopwatches, animations, and frame-rate measurements must use monotonic time. Clocks must use wall-clock time. Using the wrong one produces the wrong answer, and the failure is often subtle.

When the wrong clock breaks a stopwatch

The distinction is invisible to most users, but it is the difference between a timer that runs correctly through an NTP correction and one that suddenly gains or loses a second for no reason. A stopwatch built on Date.now() will jump when the system clock slews. A clock built on performance.now() will drift away from civil time within minutes.

Browser clock vs dedicated hardware clocks

A browser clock is a software convenience. A dedicated hardware clock is a device designed for one job, and it does that job with components a browser cannot touch.

A GPS-disciplined clock receives time signals directly from satellites and uses them to discipline a local oscillator. It is accurate to within a few nanoseconds of UTC. A radio-controlled clock picks up broadcast time signals from national laboratories. An NTP server connected to a stratum-1 source is accurate to within a few thousandths of a second of true time over a network.

What the browser lacks

A browser clock is none of these. It is a software layer on top of a quartz oscillator that may or may not be synced, showing time that may or may not be correct, with a precision that suggests an accuracy it does not have. The gap matters when the use case demands it. A wall clock in a lobby does not care about a 200-thousandth error. A scientific experiment measuring reaction time does.

Trust and verification

The practical difference is one of trust. A hardware clock that is wrong is visibly wrong, and it can be checked and corrected. A browser clock that is wrong is indistinguishable from one that is right, unless you have a reference to compare against.

NTP vs browser time: key differences

NTP is a network protocol. Browser time is a system call. The differences between them are the differences between a chain and its weakest link.

NTP is a protocol for distributing time across a network. It has a concept of distance from the reference clock, called stratum, and it can detect and reject faulty time servers. Browser time is a single number pulled from the OS. It has no protocol, no source and no correction.

A process vs a snapshot

The key difference for a user is that NTP is a process that runs continuously, while browser time is a snapshot taken at a moment. A page that shows a live clock takes a new snapshot every frame, but each snapshot is just as dependent on the OS clock as the last.

Where your browser sits in the NTP hierarchy

The NTP protocol organises time sources into a hierarchy. Stratum 0 is an atomic clock or GPS receiver, the reference itself. Stratum 1 is a server directly connected to a stratum-0 source. Stratum 2 is a server that queries a stratum-1 server, and so on.

The typical end-user device is stratum 3 or 4. Your laptop asks a time server, which asks another server, which asks another, and eventually the chain reaches an atomic clock. Each hop adds a small amount of uncertainty, but the bigger problem is that your device does not know its own level. The browser has no API to query NTP status, stratum position or last sync time. From the page's perspective, the entire NTP hierarchy is a black box.

What the browser cannot tell you

A browser clock cannot tell you whether your system clock is synced. It cannot tell you how long ago the last sync was, or how far the clock has drifted since. It can only tell you what the OS clock says, right now, to the thousandth of a second, with no indication of whether that thousandth is worth trusting.

How to check if your browser clock is accurate

The only reliable way to check a browser clock is to compare it against a reference you trust, and to watch the seconds roll over rather than reading a static number.

Put a precision seconds counter next to a radio time signal, a phone on network time, or a second device 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. The eye sees a digit and assumes it is current, but a clock that shows 14:47:13 could be anywhere within that second.

Practical checks

• Mobile networks and mobile operating systems sync aggressively, so a phone is usually closer to true time than a desktop.
• 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. A device that has been suspended for hours has not been syncing, and a device that has crossed time zones may be showing the wrong local time even though its UTC clock is fine.

What a web page can and cannot do

A web page cannot correct a wrong system clock, and it should not pretend to. JavaScript has no permission to set the operating system clock, and no legitimate page would attempt it. What a page can do is be honest about the limits of its own readout.

When browser clock accuracy matters (and when it does not)

For most uses, the accuracy of a browser clock is irrelevant. A wall clock in a kitchen, a timer on a phone, a countdown on a presentation screen: all of these work perfectly well with a clock that is off by a second or two. The human eye cannot perceive a half-second error in a clock that updates once per second, and nobody schedules a meeting by the second.

Measurement vs display

The cases where accuracy matters are the cases where the clock is doing measurement rather than display. A stopwatch that measures a race, a timer that logs events, a page that timestamps user actions: these need monotonic time and a synced system clock. A browser clock that is off by five seconds will produce timestamps that are off by five seconds, and no amount of on-screen precision will fix that.

The leap second phase-out

The next change coming is the gradual elimination of leap seconds, which international timekeepers have voted to phase out by 2035. For the first time in decades, the definition of civil time will change. Browsers do not need to do anything for this, because they do not handle leap seconds themselves. The OS does, and the browser reads the OS. But it is a reminder that the time you see in a browser is a negotiated, corrected, occasionally adjusted estimate, not a direct line to an atomic clock.

A browser clock is a convenience, not an instrument. It is accurate enough for every human purpose and not accurate enough for any machine purpose. The browser sits at the end of a chain it cannot see, reading a clock it cannot correct, showing a time that is as good as the system beneath it. That is all it can do, and for almost everything, that is enough.