iOS Testing

iPhone Screen Checker

Test your website across all iPhone viewport sizes and Safari quirks

Select Device

iPhone 12/13

390 × 844px (Portrait)

Enter a URL above to start testing

About This iPhone Test

iPhone users represent a disproportionately high-value audience — typically higher engagement, higher conversion rates, and higher spending than the average web user. Yet Safari on iOS has enough rendering quirks and CSS differences from Chrome that websites tested only in desktop browsers frequently have iPhone-specific issues that go undetected until users complain.

An iPhone screen checker simulates the exact viewport dimensions of specific iPhone models, from the compact iPhone SE (375x667px) to the expansive iPhone 15 Pro Max (430x932px). Beyond viewport size, iPhone testing must account for Safari-specific CSS behavior, the dynamic island and notch safe areas, and iOS's unique handling of inputs, scroll, and fixed positioning.

With iPhone accounting for roughly 27% of global smartphone market share and over 50% in many Western markets, iPhone-specific bugs aren't edge cases — they're mainstream problems that directly impact your bottom line.

What Makes iPhone Testing Unique

Safari on iOS is the only browser engine allowed on iPhones — Chrome, Firefox, and every other iOS browser all use WebKit under the hood. This means iOS-specific rendering differences affect every iPhone user regardless of which browser app they use.

Safari has historically lagged behind other browsers in CSS support, though it has caught up significantly. It still handles certain properties differently: 100vh includes the browser chrome on some iOS versions, causing layouts to appear taller than expected. The rubber-band scroll effect can cause fixed elements to misbehave. Input focus triggers scroll adjustments that can unexpectedly shift page layout.

Modern iPhones also have the Dynamic Island (iPhone 14 Pro and later) or notch (earlier models), requiring env(safe-area-inset-*) CSS variables to ensure content isn't hidden behind these hardware features. Sites that ignore safe areas have buttons cut off and content obscured in full-screen modes.

Key Considerations for iPhone Testing

Safe Area Insets

iPhones with Dynamic Island or notch require safe-area-inset CSS variables to prevent content from being obscured. Fixed headers, footers, and full-screen elements must account for these insets using env(safe-area-inset-top), env(safe-area-inset-bottom), etc.

100vh Behavior

On Safari iOS, 100vh equals the full viewport height including the browser toolbar. This makes elements sized to 100vh taller than the visible area, causing layout overflow. Use min-height: -webkit-fill-available or the new svh/dvh units as workarounds.

iOS Input Quirks

iOS automatically zooms into focused inputs smaller than 16px font-size. Inputs also trigger keyboard appearance that shifts the viewport, potentially pushing fixed elements off screen. These behaviors require specific CSS and JavaScript handling.

Momentum Scrolling

iOS uses momentum-based scroll with rubber-band effects at boundaries. Custom scroll containers need -webkit-overflow-scrolling: touch for smooth scrolling. Fixed positioned elements can jump or flicker during iOS scroll due to how WebKit composites layers.

Common iPhone Issues to Watch For

Safari-Specific CSS Issues

  • 100vh layouts taller than the visible screen due to Safari's viewport height calculation
  • Gap property in Flexbox not working on older iOS versions (pre-iOS 14.5)
  • position: sticky not working inside overflow containers
  • Backdrop-filter requiring -webkit- prefix for blur effects

Safe Area Problems

  • Fixed bottom navigation hidden behind iPhone home indicator
  • Full-screen hero sections with content obscured by Dynamic Island
  • Modal close buttons unreachable behind notch area
  • Horizontal scrolling content cut off by side safe areas in landscape

Input and Form Issues

  • Unwanted zoom on input focus when font-size is below 16px
  • Keyboard appearance causing fixed elements to overlap form fields
  • Date and time inputs rendering as iOS native pickers instead of custom designs
  • Autocomplete styling that overrides custom input appearance

How to Fix Common iPhone Issues

Fix 100vh on Safari iOS

The most common iPhone layout bug is elements taller than the visible screen. Use dynamic viewport units or the fill-available workaround:

/* Modern approach using dynamic viewport units */
.hero {
  min-height: 100dvh; /* Dynamic viewport height — excludes browser chrome */
}

/* Fallback for older iOS versions */
.hero {
  min-height: 100vh;
  min-height: -webkit-fill-available;
}

/* Set on html for fill-available to work correctly */
html {
  height: -webkit-fill-available;
}

Add Safe Area Insets

Prevent content from being hidden behind the Dynamic Island or home indicator:

/* Add to your HTML head */
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">

/* Then in CSS */
.fixed-header {
  padding-top: env(safe-area-inset-top);
  top: 0;
}

.fixed-footer {
  padding-bottom: env(safe-area-inset-bottom);
  bottom: 0;
}

/* For full-screen sections */
.fullscreen {
  padding:
    env(safe-area-inset-top)
    env(safe-area-inset-right)
    env(safe-area-inset-bottom)
    env(safe-area-inset-left);
}

Fix Safari Flexbox Gap

The gap property in Flexbox wasn't supported until iOS 14.5. For broader compatibility, use margins as a fallback:

/* Safe Flexbox gap with fallback */
.flex-container {
  display: flex;
  flex-wrap: wrap;
  margin: -8px; /* Negative margin trick */
}

.flex-item {
  margin: 8px; /* Fallback for old iOS */
}

/* Override with gap for modern browsers */
@supports (gap: 1px) {
  .flex-container {
    gap: 16px;
    margin: 0;
  }
  .flex-item {
    margin: 0;
  }
}

Common Use Cases

  • Pre-launch testing of landing pages for iOS users
  • Debugging Safari-specific CSS rendering issues
  • Testing fixed navigation and footer behavior on iPhone
  • Verifying form usability and input behavior on iOS
  • Checking safe area handling for full-screen experiences

Pro Tip

Always add viewport-fit=cover to your viewport meta tag when using safe-area-inset variables. Without it, the browser won't extend into the safe area and the env() variables will return 0.

Frequently Asked Questions

What are the iPhone screen sizes I should test?+
The key iPhone viewports are: 375x667px (iPhone SE, iPhone 8), 375x812px (iPhone X/11 Pro), 390x844px (iPhone 12/13/14), 393x852px (iPhone 15), 414x896px (iPhone 11), and 430x932px (iPhone 14/15 Pro Max). Testing at 375px and 430px covers the most common and extreme current iPhone sizes.
Why does my website look different in Safari vs Chrome on iPhone?+
On iPhone, Chrome, Firefox, and all other browsers are legally required to use Apple's WebKit rendering engine. So the rendering is actually identical across all browsers on iPhone. If you're seeing differences, it's likely due to browser-specific UI chrome (address bar height, toolbar position) rather than actual rendering differences.
How do I prevent iOS from zooming in on form inputs?+
Set font-size to at least 16px on all input elements. iOS Safari automatically zooms into inputs below 16px to make them readable. This zoom disrupts your layout and is one of the most common iPhone-specific UX complaints. Adding font-size: 16px to input, select, and textarea in your CSS prevents this behavior globally.
What is viewport-fit=cover and when should I use it?+
viewport-fit=cover extends your website's content into the iPhone's safe areas (behind the Dynamic Island, notch, and home indicator). You should use it when you want full-bleed backgrounds or edge-to-edge designs. Always pair it with env(safe-area-inset-*) padding on any fixed elements to prevent important content from being hidden behind hardware features.
Why does position: fixed break on iOS Safari?+
iOS Safari's momentum scroll and layer compositing can cause fixed elements to jump or render incorrectly during scroll. Common fixes include adding transform: translateZ(0) to fixed elements to force GPU compositing, using position: sticky instead where possible, and avoiding fixed positioning inside overflow: scroll containers.

Other Responsive Checkers