If your login code expired, stop entering old codes and protect one clean sign-in attempt. Use the newest code email tied to the login page you still have open, retire older messages unless the provider explicitly says otherwise, and request one fresh code only through the provider's official flow when the page says the code is expired, invalid, or already used. Do not assume every OTP lasts the same amount of time, and do not assume every resend handles old codes the same way.
The practical goal is not to guess harder. It is to reduce the number of active attempts until you know which code belongs to the current screen. Providers control expiration, validation, and retry rules. Your job is to keep the inbox, timestamp, and login page aligned.
The stale-code problem in one minute
An expired login code is usually a coordination problem: the service created a time-sensitive secret, your inbox may contain several similar emails, and the login page may be waiting for only one current attempt. The visible symptom is simple, such as "code expired" or "invalid code," but the cause can be one of several branches:
- You copied a code from an older email after requesting a newer one.
- You waited long enough that the newest code no longer matches the active login attempt.
- You opened the right email but the wrong login tab, browser profile, or device still has an older attempt.
- You requested several codes quickly and lost the timestamp trail.
- The provider has its own one-time-use, rate-limit, expiration, or resend behavior.
NIST authentication guidance treats one-time secrets as authentication factors with service-controlled validation requirements. That is why this guide avoids universal expiration claims. A provider can document a specific window for its own flow, but a blog post should not turn one provider's rule into a rule for every login.
Freshness ladder: which code should you use?
Use this ladder before you copy another OTP. Start at the top and stop as soon as one branch clearly applies.
| Ladder step | What you know | What to do | What to retire |
|---|---|---|---|
| 1. Current page, newest email | The login page is still waiting and you have one newest code from the expected sender. | Try that newest code once. Confirm the recipient address or alias matches the account you are signing into. | Older emails from the same service and older browser tabs. |
| 2. Several code emails | You requested more than one code and the inbox has a stack of similar messages. | Sort by time. Open the newest matching message first. If the page rejects it, stop and request one clean code instead of walking backward through the stack. | All older codes unless the provider's official screen says they are still usable. |
| 3. Page says expired, invalid, or used | The provider is telling you the current attempt is not valid. | Clear the attempt: return to the official login flow, request one new code, and keep that tab active. | The expired page state and every older email. |
| 4. Wrong address or alias | The code went to a personal address, alias, shared inbox, or workspace account you did not expect. | Restart with the correct account address visible before requesting a new code. | Codes sent to the wrong account context. |
| 5. Repeated failures | The newest code from the right sender fails after one careful try. | Stop retrying and use the provider's recovery, support, or alternate verification path. | Guessing, repeated resend loops, and attempts to bypass account security. |
The ladder is intentionally conservative. Trying every old code in a mailbox is noisy and can lock you into stale state. One active login page plus one newest provider email is easier to reason about.
How to find the newest code without opening everything
If the code arrived by Gmail, use documented search operators rather than broad inbox scrolling. Google documents operators such as from:, to:, subject:, newer_than:, after:, and older:. Start with the service name and code words, then narrow only when needed.
Useful searches:
| Situation | Example Gmail search | Why it helps |
|---|---|---|
| You know the service name | acme "verification code" newer_than:1d | Finds recent messages that mention the service and code phrase. |
| You know the sender | from:security@example.com newer_than:1d | Filters to the expected sender before you choose the newest email. |
| You know the subject pattern | subject:("login code") newer_than:1d | Narrows repeated notification emails from the same provider. |
| You may have used an alias | to:work-alias@example.com "code" | Checks whether the code was sent to a different address than the one you are watching. |
| You requested codes yesterday and today | "verification code" after:2026/9/5 | Keeps older attempts out of the result set. Replace the date with your actual login day. |
Do not infer more than the search results show. Gmail can help you locate candidate emails, but the provider decides whether any given code is still valid.
When to wait, retry, or reset the login flow
Use the provider's on-screen message first. If it says the code expired, invalid, already used, or too many attempts were made, treat that as stronger evidence than an old email.
A safe retry pattern looks like this:
1. Stop typing codes from older messages.
2. Confirm the account address, inbox, browser profile, and device.
3. Search for the newest email from the expected sender.
4. Try the newest code once if the page is still active.
5. If it fails, go back to the official login start screen and request one fresh code.
6. Wait for that newest message instead of clicking resend repeatedly.
7. If the fresh code still fails, switch to the provider's recovery or support path.
Waiting can be better than resending when you are not sure which inbox receives the code. Resending can be better when the provider clearly says the current code expired. Resetting the login flow is best when the page state, browser profile, or email trail is already confused.
Provider-specific expiration examples need provider-specific sources
It is tempting to ask, "How long do login codes last?" The safe answer is: it depends on the provider and the flow. Supabase, for example, documents passwordless email sign-in behavior for its own magic-link and OTP flows, including provider-specific request and expiration defaults on its docs page. That is useful as an example of why official provider documentation matters, not as a universal login-code rule.
For your own account, trust the service's login screen, help center, or security documentation over a generic article. If a provider names a time window, use that provider's current page for that provider only. If it does not, avoid guessing.
What not to do with expired OTPs
Do not treat expired codes as a puzzle to brute-force. Avoid these shortcuts:
- Do not paste codes into shared documents, tickets, chat threads, or logs.
- Do not ask someone else to forward a code unless the provider explicitly supports that workflow; forwarded login emails can add stale links, wrong-device state, and privacy risk.
- Do not disable MFA or security checks to get around a failed code.
- Do not claim a resend invalidates every older code unless that exact provider documents it.
- Do not keep requesting new codes while you are still searching for the previous one.
If repeated failures block important work, escalate through the provider's official recovery or admin path. That is slower than guessing, but it keeps the account boundary intact.
Where MagicLess fits
MagicLess is built around a narrow pain point: surfacing fresh login codes and magic links from connected Gmail inboxes on the page that needs them. That can reduce inbox switching, but it does not change provider rules. It cannot make an expired code valid, force an email to arrive, or decide that an old OTP is acceptable.
Use the freshness ladder first. If the recurring problem is that login codes interrupt work across connected Gmail inboxes, then evaluate a helper like MagicLess with the same constraints in mind: newest message, expected sender, visible user control, and no bypassing provider security.
FAQ
What should I do first when a login code expired?
Stop entering old codes. Confirm the active login page, the account address, and the newest email from the expected sender. If the page says the code expired, return to the official login flow and request one clean fresh code.
Which verification code should I use if I requested several?
Use the newest matching code tied to the current login attempt. Retire older emails unless the provider explicitly says older codes remain valid. If the newest code fails once, reset the attempt rather than walking backward through older messages.
Does requesting a new code always invalidate older codes?
Do not assume that. Some providers document specific resend or expiration behavior, but the rule is provider-specific. Cite the provider's official documentation before making that claim for a named service.
How long do login codes last?
There is no safe universal answer. Login-code lifetime depends on the provider, authenticator type, and implementation. Use the provider's current login screen or help documentation for that account.
Is an expired login code a security problem?
Usually it is a normal sign-in failure, not proof of compromise. It becomes risky when people respond by sharing codes, saving them in logs, disabling protections, or trying to bypass recovery. Keep the code private and use the provider's official recovery path when normal login fails.
Sources checked
- NIST SP 800-63B supports the general claim that one-time authentication secrets are implementation-controlled and time-sensitive; this guide uses that source to avoid universal OTP lifetime claims.
- Supabase passwordless email documentation is used only as a provider-specific example showing that official providers may document their own request and expiration defaults; it is not treated as a universal rule for all login codes.
- Gmail search operator help supports the concrete inbox-search examples in this article; it does not validate whether a provider will accept a found code.
Claim ledger
| Claim used in this guide | Source | Checked | How the claim is limited |
|---|---|---|---|
| One-time authentication secrets are service-controlled authentication mechanisms, so this guide should not state a universal OTP lifetime. | NIST SP 800-63B | 2026-09-05 | Used for general security framing only, not provider-specific expiry windows. |
| Provider-specific passwordless email flows can document their own request and expiration defaults. | Supabase passwordless email sign-in docs | 2026-09-05 | Used only as an example of provider-specific documentation; not generalized to all login codes. |
Gmail search operators such as from:, to:, subject:, newer_than:, after:, and older: can help narrow code-email searches. | Gmail search operator help | 2026-09-05 | Used only for finding likely emails; Gmail search does not prove a code is valid. |
- NIST SP 800-63B, authentication and one-time-secret framing, checked 2026-09-05: https://pages.nist.gov/800-63-4/sp800-63b.html
- Supabase passwordless email sign-in docs, used only as a provider-specific example, checked 2026-09-05: https://supabase.com/docs/guides/auth/auth-email-passwordless
- Gmail search operator help, checked 2026-09-05: https://support.google.com/mail/answer/7190?hl=en