OTP Autofill for SMS: Android, iOS and Web Formats

Your Example code is 123456.

@example.com #123456

How does OTP autofill work on the web?

Add the attribute first, then the JavaScript for browsers that support it.

<input type="text" inputmode="numeric"
       autocomplete="one-time-code" name="otp" />

Chrome's documentation recommends the attribute for cross-browser compatibility, and says Safari uses it to suggest the code from a correctly formatted SMS even though it lacks the WebOTP JavaScript API.

For Chrome on Android, call WebOTP with the sms transport. The API needs a secure origin (HTTPS), and an AbortController lets you cancel the pending request if the user types the code by hand.

if ("OTPCredential" in window) {
  const ac = new AbortController();
  const form = document.querySelector("form");
  const input = document.querySelector("input[autocomplete=one-time-code]");

  form.addEventListener("submit", () => ac.abort());

  navigator.credentials
    .get({ otp: { transport: ["sms"] }, signal: ac.signal })
    .then((otp) => {
      input.value = otp.code;
      form.submit();
    })
    .catch(() => {}); // user dismissed, or no matching SMS
}

The SMS must follow the origin-bound format in the WICG specification and Chrome's guide: a code of four to ten alphanumeric characters with at least one number before the last line, then a last line that starts with @, the host, a single space and # plus the code. The host must contain no whitespace.

Can one SMS work on Android, iOS and the web?

Often yes, because the rules are compatible. Put the human-readable text first, the Android hash on a line above the end, and the domain-bound line last. This layout is built from the documented rules, not a vendor guarantee, so test it.

Your Example code is 483921. Do not share it.
Ab3dE+9xYz1
@example.com #483921

Why this order: Apple and the web specification both want the domain and code on the last line. Google requires the 11-character hash somewhere in the message but, in the page we checked, does not fix its position. The example above is 78 bytes in plain Latin characters, comfortably inside the 140-byte limit.

Checklist before you ship:

1. Code is a single token, clearly separated from other digits in the text.
2. Domain on the last line matches the site and the app's associated domain.
3. Total length is within 140 bytes for the Retriever variant.
4. Hash matches the signing key of the build under test.
5. Tested on a handset from each platform, on the operators you actually send through.

What about Arabic and Unicode text?

Keep the code and the two machine-readable parts plain. Google's limit is in bytes, and a Unicode SMS fits far fewer characters than a GSM-7 one: 70 against 160 in a single segment (see SMS character limits and Unicode). An Arabic sentence therefore consumes the budget quickly, and one non-GSM character switches the whole message to Unicode.

Safe approach: keep the code in Latin digits, keep @domain #code in ASCII, and keep the Arabic wording short. We found no official documentation describing autofill of codes written in other digit systems, so we leave that out and recommend testing before use.

How do WhatsApp authentication templates handle autofill?

Meta's authentication templates come with three button styles, each with a fixed body text of the form <code> is your verification code.

Meta's documentation also notes that on iOS 26 and later, keyboard suggestions provide autofill with no integration, and that users on platforms without zero-tap receive a copy-code button. You can set an expiry with code_expiration_minutes, and the preview API accepts values from 1 to 90 minutes. Compare the channels in WhatsApp OTP vs SMS OTP.

Worked example: a ride-hailing app login

"Qafila Rides" (synthetic) has an Android app, an iOS app and a mobile site at qafila.example.

1. The Android app starts the SMS Retriever when the user taps "Send code".
2. The backend generates a six-digit code, valid for a few minutes, and sends the three-line message above through the SMS API.
3. Android hands the message to the app. iOS offers the code above the keyboard. On the mobile site, Safari suggests it and Chrome fills it via WebOTP.
4. The server validates the code once, rejects reuse and expired codes, and rate-limits requests.
5. If the SMS is not confirmed within a short timeout, the backend offers a WhatsApp authentication template as a second path.

What are the common mistakes?

• Code not on its own. Extra numbers (phone, price, date) beside the code confuse detection. Use one code per message.
• Wrong hash. The hash follows the signing certificate. A hash from a debug key will not match a production build.
• Domain mismatch. @example.com must match the site or associated domain, otherwise iOS and WebOTP will not offer the code.
• Broken last line. Anything after #code, a missing space, or whitespace inside the domain breaks the format.
• Message too long or Unicode-heavy, which exceeds the 140-byte Retriever limit.
• Listening too late. The User Consent API ignores messages received before it started.
• Using autofill as security. Autofill is convenience. Still validate server-side, expire codes and limit attempts, and watch for SMS pumping fraud.
• Scope. This guide covers documented behaviour at the time of writing. Platform rules change, so check the linked sources before release.

For message wording and expiry choices, see our OTP and authentication messages guide.

How OmniChannels.ai helps

OmniChannels.ai sends OTP through SMS and WhatsApp over BroadNet's direct operator connectivity, so you can control the exact message text your autofill format depends on. WhatsApp templates cover copy-code, one-tap and zero-tap authentication. Channel fallback, for example WhatsApp then SMS, is configured per use case, and delivery statuses arrive in one webhook format. See the SMS API docs, the WhatsApp API docs and the OTP solution.