Your mobile checkout is leaking.

The mobile conversion gap.

The median desktop checkout completion rate across ecommerce is approximately 46%. The median mobile checkout completion rate on the same stores is approximately 26%. That 20-point gap represents a significant and recoverable revenue opportunity for most stores.

The gap is not explained by intent — mobile visitors are not lower-intent buyers. It's explained by friction. Mobile devices introduce a set of specific UX constraints that desktop ignores: smaller tap targets, software keyboards that obscure form fields, viewports that don't accommodate side-by-side layouts, and network conditions that make large pages slow.

None of these are engineering problems. They're design and configuration problems. Most of the patterns below are fixable with CSS changes, HTML attribute additions, or image optimisation — not sprint work.

Pattern #1 — Tap target failures.

The minimum recommended tap target size is 44×44px (Apple HIG) or 48×48dp (Google Material). Most ecommerce checkouts have interactive elements smaller than this — particularly on form labels, close buttons, and secondary links.

What we see on scans

• "Edit" links in the order summary at 12px font with no padding.
• Close or dismiss buttons on modals at 24×24px.
• Radio buttons for shipping options with tap targets of 16px — the button itself, with no surrounding click area.
• Checkbox inputs for terms and conditions with no associated label extending the tap area.

What to ship

Every interactive element in the checkout flow needs a minimum 44px tap target. This is almost always a padding addition, not a size change to the visible element.

/* Quick fix for small interactive elements */
.edit-link, .close-btn, input[type="radio"], input[type="checkbox"] {
  min-height: 44px;
  min-width: 44px;
  padding: 12px;
}

For radio buttons and checkboxes, extend the tap area to the full label via <label> wrapping — the native HTML pattern that costs zero CSS.

Typical lift from fixing tap targets across the checkout flow: +2% to +5% on mobile form completion.

Typical impact: medium — compounds with the other patterns in this guide.

Pattern #2 — Wrong keyboard type.

Every form field in a checkout has an optimal keyboard type for mobile. Most checkouts use the default text keyboard for every field, requiring users to manually switch to number or email keyboards for inputs that obviously need them.

What we see on scans

• Credit card number fields (type="text") triggering a full QWERTY keyboard instead of a numeric pad.
• Phone number fields without type="tel".
• Email fields without type="email".
• Postcode/ZIP fields without inputmode="numeric".

What to ship

This is the fastest fix in this guide. Four HTML attribute changes:

<!-- Email field -->
<input type="email" autocomplete="email" />

<!-- Phone field -->
<input type="tel" autocomplete="tel" />

<!-- Card number -->
<input type="text" inputmode="numeric" pattern="[0-9\s]*" autocomplete="cc-number" />

<!-- Postcode / ZIP -->
<input type="text" inputmode="numeric" autocomplete="postal-code" />

Shipping this takes under an hour. The user experience improvement is immediate and significant — entering a card number on a numeric pad vs a QWERTY keyboard is the difference between a smooth interaction and an avoidable error.

Typical lift from correct keyboard types across the checkout: +3% to +6% on mobile form completion.

Typical impact: medium — disproportionately high impact relative to implementation cost.

Pattern #3 — CTA buried below the fold.

On mobile, the primary checkout CTA is frequently pushed below the fold by the order summary, shipping options, or payment form — meaning the user has to scroll to find the action they're trying to take.

What we see on scans

• Order summaries that expand to full height before the CTA, requiring scroll on all but the largest phones.
• Payment form with all fields visible simultaneously — 10 fields stacked vertically, CTA at the bottom.
• Desktop-style side-by-side layouts (order summary left, payment form right) that collapse to full-width stacks on mobile, doubling the page height.

What to ship

Option A — Sticky CTA. A sticky "Place order" button fixed to the bottom of the viewport, always visible, regardless of scroll position. This is the single highest-impact mobile checkout change for most stores.

.checkout-submit-btn {
  position: sticky;
  bottom: 0;
  width: 100%;
  z-index: 100;
  padding: 16px;
}

Option B — Collapsed order summary. Show the order total in a collapsed header (always visible) with a toggle to expand the line items. The CTA appears above the form, not below the summary.

Typical lift from a sticky CTA on mobile: +5% to +12% on checkout completion.

Typical impact: high — this is usually the highest-ROI single change for mobile checkout.

Pattern #4 — Disabled or broken autofill.

Browsers and password managers save address, payment, and contact data to autofill on checkout forms. A significant percentage of mobile checkouts break autofill — either by disabling it explicitly, using non-standard field names, or building custom inputs that the browser doesn't recognise.

What we see on scans

• autocomplete="off" on address and payment fields — explicitly disabling browser autofill.
• Custom-styled select dropdowns built in JavaScript that don't accept browser-injected values.
• Field names that don't match the autocomplete attribute vocabulary, causing autofill to silently fail.
• Card input components that intercept keystrokes and prevent password manager integration.

What to ship

Use the standard autocomplete attribute vocabulary on every checkout field. The full list is specified in the HTML Living Standard — the most important ones for checkout:

<input autocomplete="given-name" />       <!-- First name -->
<input autocomplete="family-name" />      <!-- Last name -->
<input autocomplete="email" />
<input autocomplete="street-address" />
<input autocomplete="address-level2" />   <!-- City -->
<input autocomplete="address-level1" />   <!-- State/province -->
<input autocomplete="postal-code" />
<input autocomplete="country" />
<input autocomplete="tel" />
<input autocomplete="cc-number" />        <!-- Card number -->
<input autocomplete="cc-exp" />           <!-- Expiry -->
<input autocomplete="cc-csc" />           <!-- CVV -->

Never use autocomplete="off" on checkout fields unless required by PCI compliance (which it isn't, for most implementations).

Typical lift from fixing autofill compatibility: +4% to +9% on mobile checkout completion.

Typical impact: high — particularly on returning customers who have stored their details.

Pattern #5 — Trust signals missing on mobile.

Desktop checkouts typically include trust signals — security badges, money-back guarantees, card logos — in a sidebar or below the payment form. On mobile, that sidebar collapses, and the trust signals either move to below the fold or disappear entirely.

What we see on scans

• Trust signals visible on desktop (card logos, padlock, guarantee) that are hidden or pushed below the primary CTA on mobile.
• Security copy ("256-bit SSL encryption") in the desktop sidebar that doesn't appear at all in the mobile stack.
• "30-day money-back guarantee" prominent on the product page but absent from the mobile checkout.

What to ship

On mobile, trust signals belong above the primary CTA, not below it. The moment of hesitation before the final tap is the moment they need to appear.

A single line immediately above the "Place order" button handles most of the trust work: card network logos (Visa, Mastercard, Amex at 24px height), a padlock icon, and one line of guarantee copy. This takes one component and eight lines of CSS.

Typical lift from repositioning trust signals above the mobile CTA: +3% to +7% on final checkout completion.

Typical impact: medium — higher for first-time buyers and higher-ticket items.

Pattern #6 — Viewport overflow.

Horizontal overflow on mobile — content that extends beyond the viewport width — is one of the most consistent mobile checkout issues and one of the least noticed by the teams building the checkout. It's invisible on desktop. On mobile, it breaks the layout in ways that are immediately apparent to users.

What we see on scans

• Desktop-width tables or grids that overflow the mobile viewport, causing horizontal scroll.
• Fixed-width elements (width: 600px) that exceed the mobile viewport and clip content.
• Images without max-width: 100% that extend beyond their containers on small screens.
• Modals with fixed pixel widths that don't adapt to the viewport.

What to ship

/* Prevent all horizontal overflow */
* {
  box-sizing: border-box;
  max-width: 100%;
}

img, video, iframe {
  max-width: 100%;
  height: auto;
}

/* Audit all fixed-width containers */
.fixed-width-container {
  width: 100%;
  max-width: 600px; /* preserve desktop width, allow mobile collapse */
}

Audit using Chrome DevTools responsive mode at 390px width. Any element that triggers a horizontal scrollbar is a viewport overflow issue.

Typical lift from fixing viewport overflow in the checkout: +2% to +4% on mobile completion.

Typical impact: low to medium — but disproportionately damaging to perceived quality, which affects trust.

Pattern #7 — Page weight on mobile networks.

Mobile users on 4G networks experience checkout pages at roughly 40–60% of the speed desktop users experience on broadband. A checkout page that loads in 1.8s on desktop may load in 4.2s on a mid-tier mobile device on a real network.

Every second of load time above 2s costs conversion. The relationship is approximately linear: +1 second load time = –7% checkout completion rate.

What we see on scans

• Uncompressed product images on the order summary (400KB+ per image, displayed at 64×64px).
• Third-party scripts loading synchronously in the checkout — analytics, chat widgets, A/B testing frameworks that add 300–800ms each.
• Full-size font files loaded for fonts used only in the checkout footer.
• No lazy loading on below-fold checkout assets.

What to ship

Three changes that address the majority of checkout page weight:

1. Compress and resize order summary images. At 64×64px display size, a 2× retina image is 128×128px. Anything above that is waste. Use WebP format, compress to ≤15KB per image.

2. Defer non-essential third-party scripts. Analytics, chat, and marketing scripts don't need to load before the checkout form is interactive. Add defer or async to their script tags, or move them to load after the DOMContentLoaded event.

3. Subset your fonts. If you're loading a full font file for a checkout page that uses two weights, subset to the characters used on that page. Tools: pyftsubset or Google Fonts text= parameter.

Typical lift from reducing checkout page weight by 30–50%: +5% to +11% on mobile checkout completion.

Typical impact: high — mobile-specific, but mobile is now the majority of checkout traffic.

How Levri spots mobile checkout leaks.

Levri renders your checkout at mobile viewport dimensions and analyses it for tap target compliance, keyboard type configuration, CTA visibility, autofill attribute coverage, trust signal positioning, viewport overflow, and page weight — then ranks each finding by its estimated impact on mobile checkout completion.

The output is specific to your page and device context: not "consider mobile optimisation" but "your card number field uses the default text keyboard instead of a numeric pad; adding inputmode="numeric" is estimated to reduce card entry errors by 40% and increase mobile form completion by 3–6%."

Fix these first.

In order of typical impact on mobile checkout completion:

1. Add a sticky "Place order" button fixed to the bottom of the mobile viewport.
2. Fix keyboard types across all checkout fields — four HTML attribute changes, under an hour.
3. Fix autofill attribute vocabulary on all address and payment fields.
4. Compress and resize order summary images to ≤15KB at 2× retina dimensions.
5. Move trust signals (card logos, guarantee copy) above the primary CTA on mobile.
6. Fix tap targets on all interactive elements to minimum 44×44px.
7. Audit at 390px width for viewport overflow. Fix any horizontal scroll triggers.

Ship steps 1, 2, and 3 in the same deploy — they're all HTML/CSS changes with no backend dependencies, and together they typically account for 60–70% of the total mobile checkout lift.

Frequently asked.

Why is my mobile checkout conversion rate lower than desktop?

The median mobile checkout completion rate is roughly 20 percentage points below desktop on the same stores. The gap is explained by friction, not intent. Mobile-specific issues — small tap targets, wrong keyboard types, CTAs pushed below the fold, broken autofill, and slower page loads on mobile networks — collectively account for most of the gap. All are fixable without redesigning the checkout.

What is the minimum tap target size for mobile?

44×44px per Apple's Human Interface Guidelines, or 48×48dp per Google's Material Design spec. Most checkout forms have interactive elements — edit links, radio buttons, checkboxes — well below this. The fix is almost always a padding addition, not a visual size change to the element itself.

How do I improve mobile checkout conversion rate?

In order of typical impact: add a sticky primary CTA fixed to the bottom of the viewport, fix keyboard types on all form fields (numeric pad for card and postcode, email keyboard for email), fix autocomplete attributes so browser autofill works, compress order summary images, and move trust signals above the CTA. These five changes together typically recover 60–70% of the mobile-desktop conversion gap.

What autocomplete attributes should I use on a checkout form?

Use the standard HTML autocomplete vocabulary on every field — given-name, family-name, email, street-address, address-level2 (city), address-level1 (state), postal-code, country, tel, cc-number, cc-exp, cc-csc. Never use autocomplete="off" on checkout fields. Broken or absent autocomplete attributes are one of the most common mobile checkout friction points and one of the easiest to fix.

Does page load speed affect checkout conversion rate?

Yes, approximately linearly — each additional second of load time above 2s costs roughly 7% checkout completion rate. The highest-impact fixes for checkout page weight are compressing order summary images to ≤15KB at retina dimensions, deferring non-essential third-party scripts (analytics, chat), and subsetting fonts to the characters used on that page.