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.