Last verified June 2026 · 8 min read

Magic link vs password vs passkey: what actually happens to conversion

What a magic link is

A magic link is a one-time, time-limited URL emailed to the user at signup or login time. The user enters their email, receives the link, clicks it, and is signed in without ever choosing or typing a password. Slack popularised the pattern at consumer scale. Notion, Medium, and Substack use it as their primary auth method.

The conversion math is simple: no password field means no password-creation friction, no password complexity rejection, no confirm-password field, and no password typo. Every one of those eliminated friction points contributes to the 15-30pp lift.

The decision matrix

Passkeys for 2026

Passkeys (WebAuthn/FIDO2 credentials) are now production-ready. They use public-key cryptography bound to the device and origin, which makes them phishing-resistant by design - a phishing site cannot intercept a passkey because the credential is tied to the origin URL. iCloud Keychain syncs passkeys across Apple devices. Google Password Manager handles Android. 1Password, Bitwarden, and Dashlane all support passkeys as of 2025.

The signup UX for a passkey is typically: enter email, biometric prompt (Face ID, fingerprint, or PIN), done. No password field. On first-time devices, the user is walked through passkey creation. The conversion lift is comparable to magic link without the repeat-login email-check penalty.

The honest complexity caveat: passkey implementation is harder than email+password. Fallback paths (what if the user is on a new device with no passkey?) must be carefully designed. Auth vendors (Auth0, Clerk, Stytch) have abstracted most of this, but it still requires more thought than a standard email+password form.

When password still wins

Shared accounts (a team shares one login), kiosk environments (public terminals without reliable email access), and users with poor email deliverability all benefit from a persistent password. The password is still the most universally accessible credential. Never remove it entirely - always offer it as a fallback even if magic link or passkey is the primary.

Alternatives to magic links

If the repeat-login email-check penalty rules magic links out, four alternatives cover most cases. Each removes or reduces password friction differently.

• One-time passcode (OTP). The closest sibling to a magic link: the user is emailed (or SMS-texted) a short numeric code and types it in, instead of clicking a link. Email OTP keeps the same inbox round-trip as a magic link but works when link-rewriting security scanners silently consume the link before the user clicks. SMS OTP delivers faster and works without an email client, but carries per-message cost, deliverability gaps in some countries, and SIM-swap risk - it is the weakest of the four on security. Prefer email OTP or a magic link over SMS OTP where you can.
• OAuth / social login. Google, Apple, GitHub, or Microsoft sign-in. No email round-trip at all - the fastest path when the user already has an account with the provider. The trade-offs are provider dependency, the account-linking problem when a user returns with a different provider, and reduced control over the profile data you receive. See our OAuth vs email page for the conversion detail.
• Passkeys. The strongest option and the one that removes both password-creation friction and the repeat-login penalty: biometric tap on return, phishing-resistant by design. The cost is higher implementation complexity and the need for a well-designed fallback for new or unsupported devices. Covered in the section above.
• Password with a good UI. Not an alternative to be dismissed. A single password field with a visibility toggle, NIST-aligned rules (length over forced complexity), no confirm-password field, and a paste-friendly input converts far better than a badly built password form. If you cannot ship any passwordless method, fixing the password UI is the highest-leverage move.

The NIST caveat

A common misconception is that NIST recognises email magic links as an AAL1 authenticator. It does not. NIST SP 800-63B-4 (the final 2025 revision) states that "email SHALL NOT be used for out-of-band authentication" because it can be accessed with only a password and intercepted in transit. An emailed magic link is therefore not an approved NIST authenticator at any AAL (email confirmation and recovery codes are a separate, permitted use and are unaffected). Passwords and passkeys are recognised authenticators: a password meets AAL1, passkeys meet AAL2, and AAL3 requires a hardware authenticator with verifier-impersonation resistance. The practical takeaway for product teams: most consumer SaaS is not bound by NIST AALs and can use magic links freely, but if you operate under a NIST-aligned framework (federal systems, or sectors that adopt it), a magic link cannot be your sole login factor - pair it with or graduate users to a password or passkey. See NIST 800-63B for product teams.