The app is open, the six digits are right there, and the service says they are invalid. Almost every page that answers this question gives the same four steps, and one of them sends you to a menu Google removed from the app two major versions ago.
So this page starts with what is actually true about the clock now, then works through the things a correct clock does not explain — including one that is specific to this app and is written down in Google's own documentation. For the general version of the problem, across any app and any service, 2FA code not working: causes and fixes, in order is the full guide. This page is about Google Authenticator; if the app in front of you is a different one, Microsoft Authenticator code not working and Authy code not working cover the failures particular to those.
The short answer
Fix the clock in your phone's settings, not in the app. Google Authenticator no longer has a clock of its own to correct: "The time correction setting is no longer available in version 7.0. The app now uses the time setting on your operating system" (Google). Turn on automatic date and time, then generate a fresh code and type it immediately.
If automatic time was already on, the clock is not your problem, and the rest of this page is the part the generic advice never reaches.
Time correction for codes: the fix that no longer exists
A good share of the pages still ranking for this question tell Android users to open Google Authenticator, go to Settings, tap Time correction for codes and choose Sync now. That instruction was correct for years. It is now a dead end, and Google says so at the top of its own Authenticator page, in bold.
That correction is worth more than its trivia value, because it generalises. Your authenticator reads the device clock; it does not own one. There is nothing inside any authenticator app to adjust, and an app advertising a clock fix is adjusting something else. The clock lives here:
- Android — Settings, System, Date & time, then Set time automatically plus the network-provided time zone.
- iPhone and iPad — Settings, General, Date & Time, Set Automatically. If it is already on, switch it off and on again to force a fresh fetch.
Google's whole troubleshooting line for a refused code is: "The time on your device is synced and correct for your local time zone" (Google). Correct is the operative word, and it is not a matter of a few seconds — for how much drift a verifier actually tolerates, and why a minute is usually fatal, see the clock section of the main guide.
Codes refused after a new phone
Two things can carry Google Authenticator onto a new phone, and they fail differently.
If your codes were saved to a Google Account, they follow the sign-in: "When you sign in to your Google Account within Google Authenticator on a new device, your codes are automatically synced to this device" (Google). If the app on the old phone was never signed in, nothing syncs, and the new phone starts empty.
If they were not, the route is the QR export — Transfer accounts, then Export accounts on the old phone, Import accounts on the new one. Moving Google Authenticator to a new phone has the full sequence and the wording variations between Android builds.
The failure worth naming here is the one that produces rejected codes rather than missing ones: somewhere in the move, an account was set up a second time. Scanning a fresh QR at a service issues a new secret and retires the old one, and the retired entry notices nothing. It keeps counting down and keeps producing well-formed six-digit codes that no longer match anything. So before you assume the app is broken, search it for the service name. Two entries is the answer you want, because it explains everything — sign in with the other one, then delete the dead entry, in that order.
When one service fails and everything else works
Run the ten-second diagnostic first: open a different account at a different service. Codes refused everywhere means the device or the clock. Exactly one service refusing means that entry.
For Google Authenticator there is a cause here that belongs to this app specifically, and it is documented by Google rather than inferred. A TOTP QR can specify a hash other than SHA-1, more than six digits, or a period other than 30 seconds. Google's own Key Uri Format specification says what its apps do with those:
Currently, the algorithm parameter is ignored by the Google Authenticator implementations.
The same page says the same thing about the other two: "Currently, on Android and Blackberry the digits parameter is ignored by the Google Authenticator implementation", and "Currently, the period parameter is ignored by the Google Authenticator implementations" (Key Uri Format).
Read what that means for a sign-in. If a service issues an eight-digit or SHA-256 or 60-second entry and you scan it into Google Authenticator, the scan succeeds, the entry looks completely normal, and the codes are computed on the defaults instead of on what the QR asked for. Every one of them is refused, for ever, and nothing in the app indicates why. It is uncommon, because most services use the defaults, but it is the one failure retrying cannot touch. The fix is to hold that account in an app that honours the parameters it was given.
The other single-service causes are not app-specific, and the main guide works through them: a secret typed in by hand rather than scanned, a verifier with a narrower acceptance window than you assumed, and a counter-based entry that has walked out of step. They are in the causes that survive a correct clock.
When no Google Authenticator code will ever work
If the clock is right, there is only one entry, and the secret you hold is simply not the secret the service holds, stop retrying. No app can reconstruct a secret it was never given, and every further attempt is a slower route to the same place.
- Spend a backup code. They exist for exactly this, because they are a bypass rather than a second copy of the factor. Where to store your 2FA backup codes covers what to do the moment you spend one.
- Look for a second factor you forgot you had — another authenticator, a security key, a browser still signed in. An active session is often enough to add a new authenticator without any formal recovery.
- Use the service's own recovery. Lost your phone? How to get your authenticator codes back sets honest expectations per service.
Where KeyNesta fits, and what it cannot do
KeyNesta cannot set your clock. It reads the device clock like every other authenticator, so when the clock is wrong the fix is in the operating system, here as anywhere.
What it does do bears on the app-specific cause above: a KeyNesta entry carries the algorithm, digit count and period the QR actually specified, so a SHA-256, eight-digit or 60-second account generates the codes that service expects instead of the default ones. The Google Authenticator export QR is also the format KeyNesta reads, so an account already in Google Authenticator can be moved without re-enrolling it — Import from Google Authenticator walks through that, and Google Authenticator alternative compares the two apps including what KeyNesta does not have.
What it cannot do is recover anything. Sync is zero-knowledge, so a forgotten passphrase is not a support ticket. If your codes are gone, the route back is the account, not the app.
Frequently asked questions
Why does Google Authenticator say my code is invalid?
Most often the device clock has drifted, because the code is computed from the time and the service checks it against its own. If automatic date and time is already on, the usual cause is a retired entry: the account was enrolled again at some point, which issued a new secret and silently stopped honouring the old one.
Where is Time correction for codes in Google Authenticator?
It is not there any more. Google says the setting was removed in version 7.0 and the app now uses the operating system's time setting, so the correction is made in Android or iOS date and time settings rather than inside the app.
Do Google Authenticator codes stop working after switching phones?
Only if the secret moved and then changed. Codes saved to a Google Account sync to the new phone and keep working; codes moved with the QR export keep working too. Codes that are refused after a move almost always mean the account was re-enrolled somewhere along the way, leaving a dead entry producing valid-looking digits.
Can a Google Authenticator code be wrong because the phone is offline?
No. Generating a code is arithmetic on the stored secret and the current time, with no network involved, which is why it works in aeroplane mode. Being offline matters only because a phone with no network cannot refresh its clock from one.
What if Google Authenticator shows codes but none of them are accepted?
Codes always look right, even when the secret behind them is dead, so a countdown ring proves nothing. If every service refuses them, suspect the clock or the whole app install. If exactly one service refuses them, suspect that entry, and check whether the service uses non-default settings that this app ignores.
Takeaway
Fix the clock in the operating system, because the app has not had that setting since version 7.0. Then run the one diagnostic that splits the problem in half: everything failing points at the device, one service failing points at that entry. After that the list is short — a retired entry still counting down, a move that quietly re-enrolled an account, or a service whose QR asked for settings Google Authenticator ignores. When none of it applies, spend a backup code rather than another attempt.