MagicLess
Guides

The code arrived, but the login rejects it

Authenticator Code Rejected? Check Your Phone's Clock

Open this page on the phone that shows your authenticator codes. It measures that phone's clock and shows how many of its codes a server would accept.

Free tool, runs in your browserChecked September 28, 2026

An authenticator app makes a new code every 30 seconds from the current time, and the server checks it against its own clock. If the phone's clock is off, the code on the screen belongs to a different 30-second step from the one the server expects, so it is rejected even when you type it correctly. Google Authenticator for Android dropped its own time-correction setting in version 7.0 and now uses the phone's time. The fix is automatic date and time on the phone; the check below tells you whether the clock is the problem.

Measuring this device's clock…

How do you fix the clock?

  • iPhone. Open Settings, tap General, then Date & Time, and turn on Set Time Automatically and Set Time Zone Automatically. Apple's guide notes that without Location Services or cellular service you set the time zone by hand.
  • Android. Google's Android Help: open the Clock app, tap More, then Settings, then Change date and time, and turn on Automatic date and time (and automatic time zone, where your phone offers it). Menu names can differ by phone maker.
  • Then measure again. A code shown after the fix should work. Microsoft gives the same instruction when Microsoft Authenticator's sign-in requests keep expiring: it "requires your mobile device clock to accurately report your local time. If your device clock is set to manual, reconfigure your system clock to automatic." Microsoft adds that you should then restart the device and check that the new time is correct.

How does the clock decide whether a code works?

The standard behind these codes, RFC 6238, counts time in 30-second steps from 1 January 1970 in UTC. The app turns the current step number and a secret it shares with the service into a code. The server does the same with its own clock and compares. RFC 6238 recommends that the server accept "at most one time step" for network delay, so a server that follows it takes the current code and the one just before it. Section 6 also lets a server accept a few steps either way for clock drift and remember a device's drift, so some servers forgive more than the table shows. Few services say which rule they use, so the table shows three common ones.

Two things follow from the math. First, even a perfect clock loses some codes on a strict server: if you press Verify 5 seconds after you read the code, the step has already changed for about 1 code in 6. That is why waiting for a fresh code when the countdown is nearly out helps. Second, on a server that uses the RFC's one-step-back allowance, a phone that runs fast fails more often than one that runs slow by the same amount, because the allowance looks back, not forward. On a server that accepts only the current step it is the other way round. As a hypothetical example, a phone 20 seconds fast, with the code typed 5 seconds after you read it, fails on about half of its codes under the "one step back" rule.

What else makes a correct-looking code fail?

If the clock checks out, work through these. The first two are on Google's own list for its app; the other two are common with any authenticator app.

  1. The code ran out while you typed. Wait for the next code and enter it straight away.
  2. The code came from the wrong entry. Apps list every account you added. Check the service name and the account name on the entry, for example two Google accounts or a work and a personal login.
  3. The entry is out of date. The code comes from a secret the service gave you when you set it up. Turning 2-step verification off and on again, or setting the app up again on the service's site, usually creates a new secret, and the old entry keeps making codes the service no longer accepts. Remove the old entry and set it up again from the service's security settings.
  4. The page wants a different code. Some sign-in pages send a code by email or text even when you have an authenticator app. Read where the page says the code went. For emailed codes the site rejects, use the stale-code check.

Setting up an app for the first time, or moving to a new phone? Read what to set up before you switch to an authenticator app, including backup codes.

Why did Google Authenticator's time sync setting disappear?

Older versions of Google Authenticator for Android had a time-correction option in the app's settings. Google's help page now says: "The time correction setting is no longer available in version 7.0. The app now uses the time setting on your operating system." So there is nothing to sync inside the app. Fix the phone's clock, which is what this page measures.

How accurate is this check, and what does it send?

The page asks our server for its time six times and keeps the answer with the shortest round trip. The error is at most half of that round trip, and the page shows it next to the result: on a normal connection it is well under a second, far smaller than a 30-second step. For a second opinion, NIST's time.gov shows how far your device's clock is from official US time.

Each request carries only this device's current time, used to stop caches from answering, and the server answers with its own time. The page never asks for a code or a setup key, and you should never type either into a site other than the one you are signing in to. It measures the device you open it on, so open it on the phone that runs your authenticator app.

Where does MagicLess fit?

MagicLess does not read authenticator apps. It handles the other common kind of code, the one a site emails you: it finds that code in the Gmail inbox you connect and offers it on the login page in Chrome, and it never submits the form for you. See what MagicLess works with.

Sources

All pages read September 28, 2026.