OTP fields must accept paste and autofill

What it is

One-time passwords arrive from SMS, email, or an authenticator; people rarely hold every digit in mind and retype them. Paste and autofill means the control accepts a whole-string paste, the system “code from Messages” suggestion, and a password manager’s one-time code—not autocomplete=off, a blocked paste, or six disconnected boxes that cannot consume a full string. This entry is only about how the code enters the field. It is not about how expiry is worded, and not about guess limits.

Why it happens

OTPs load working memory: 4–8 meaningless symbols plus an app switch. On phones, jumping to Messages and back incurs app-switch cost; the middle digits are often gone on return. Paste and OS-level autofill turn recall into recognition-and-confirm; errors shift from per-digit typos to one whole-string submit. Six separate boxes that only accept keyed digits fragment a paste into the first cell and throw the system capability away. If the input is not marked with one-time-code semantics (Web one-time-code, platform SMS retrieval APIs), the system never offers a fill.

Studying it

On real devices, compare a single pastable field, split boxes that reject paste, and fields that declare one-time-code semantics, using time and error—not submit success alone.

Independent variables: single field versus split boxes, paste interception, OS-recognizable OTP semantics, whether the SMS arrives on the same device as the app. Dependent variables: time from code-in-notification to successful submit, transposition and omission counts, round-trips to Messages, adoption of the system suggestion.

Showing the code on a test sheet in the lab erases the need to paste. Ecological validity depends on notification and app sharing a device; when SMS is read on another device, autofill is unavailable and paste must still work. Do not treat “split boxes look better” as evidence of higher accuracy—aesthetics and fill success are separate measures.

Where it stops holding

Some assistive setups and hardware keyboards prefer digit-by-digit entry; split boxes may stay if a full-string paste is distributed across cells and a screen reader treats them as one code. Authenticator-app codes have no SMS autofill channel, only paste and typing. High-security flows that fear clipboard residue should clear the clipboard after success, not ban paste. TV and in-car shells lack system SMS fill; they need a paired phone or a speakable short code, and this platform assumption does not hold.

Applying it

• Use one pastable field, or split boxes that assign digits on paste; declare one-time-code input mode and enable platform SMS retrieval.
• Do not disable paste or autocomplete on the OTP field; strip spaces and hyphens on submit.
• After success, the product may ask to clear the clipboard; on failure, keep the value so the person can edit instead of clearing the box and forcing another trip to Messages.
• Verify by pasting a six-digit code copied from another app, then on a physical device confirm that an incoming SMS produces a tappable system suggestion. Either path failing is a fail. Compare median time from notification to submit before and after the change.

Related

• Within the group: H6.03.2 OTP expiry and resend interval must be visible · H6.03.3 SMS failure needs a fallback channel · H6.03.4 A magic link must expire after one use so forwarding cannot reuse it · H6.03.5 Limit OTP guesses to stop brute-force enumeration · H6.03.6 Magic links and OTP codes are not equivalent authenticators · H6.03.7 Passwordless login still needs a device-side confirmation against intercepted links
• Adjacent: H6.04 Password rules · H1.13 Smart prefill and autofill
• Search terms: OTP autofill · one-time-code · paste into OTP