iPad Testing

iPad Screen Checker

Ensure your website works flawlessly across all iPad models and orientations

Select Device

iPhone 12/13

390 × 844px (Portrait)

Enter a URL above to start testing

About This iPad Test

iPad users engage with web content differently than phone or desktop users — longer sessions, more deliberate browsing, and higher intent. Websites that fail to properly adapt to iPad viewports miss these high-value interactions entirely. Yet the iPad's unique range of screen sizes, the introduction of iPad multitasking (Split View), and Safari's desktop-mode default on iPadOS all create testing challenges that go beyond standard responsive design.

An iPad screen checker tests your website at the exact pixel dimensions of real iPad hardware, from the compact iPad Mini (768x1024px) to the expansive iPad Pro 13-inch (1024x1366px). More importantly, it surfaces rendering issues specific to Safari on iPadOS — a distinct environment from both mobile Safari and desktop browsers that has its own quirks and capabilities.

Since iPadOS 13, Safari on iPad defaults to requesting the desktop version of websites. This means your desktop layout renders on a touch screen — creating a new category of problems where desktop-optimized interactions (hover, mouse precision) are expected but touch is the actual input method.

iPadOS: Desktop Mode on a Touch Screen

iPadOS Safari's desktop-mode default fundamentally changes iPad testing. Your desktop layout — with its hover states, small click targets, and mouse-cursor assumptions — is now being navigated with fingers on a touch screen. This hybrid context requires deliberate design decisions that neither pure mobile nor pure desktop responsive design addresses.

iPad also supports Split View multitasking, where your website can appear at reduced widths even on larger iPad screens. In Split View, an iPad Pro running at 1024px can display your site at 50% width (512px), triggering your mobile breakpoints unexpectedly. Designs must account for these in-between states.

The variety of iPad screen sizes is also wider than most developers realize. iPad Mini sits at 768px, standard iPad at 810px, iPad Air at 820px, and iPad Pro at 1024px (11-inch) or 1366px (13-inch). Each size can be in portrait or landscape, and each requests the desktop site by default on iPadOS.

Key Considerations for iPad Testing

Desktop Mode by Default

Since iPadOS 13, Safari requests desktop websites by default. Your desktop layout renders on a touch device. Ensure all interactive elements have adequate touch targets, hover-dependent UI has touch alternatives, and desktop navigation is usable with finger taps.

Split View Compatibility

iPad Split View can reduce your site's visible width to half the screen. A 1024px iPad Pro in Split View shows your site at ~512px — triggering mobile breakpoints. Test your site at Split View widths (50% of each iPad model) to ensure nothing catastrophically breaks.

Portrait and Landscape

iPads are used in both orientations extensively — unlike phones where portrait dominates. An iPad Pro in landscape at 1366px presents an almost desktop-width canvas, while portrait at 1024px sits in tablet territory. Both must be tested carefully.

Apple Pencil Interactions

iPad Pro users may interact with your site using Apple Pencil, which provides pixel-perfect precision unlike finger touch. While you don't need to design specifically for Pencil, avoid interactions that assume imprecise touch — precise interactions also work well with Pencil.

Common iPad Issues to Watch For

Desktop Layout on Touch

  • Hover-only dropdown navigation with no tap alternative on iPad
  • Tooltip content only accessible on hover, invisible to iPad users
  • Small click targets designed for mouse precision, unusable with touch
  • Drag interactions without touch event equivalents

Split View Problems

  • Layouts that break at non-standard widths triggered by Split View
  • Fixed-width sidebar that collapses entire layout in Split View mode
  • Navigation that doesn't adapt to narrow Split View widths
  • Tables and data grids that overflow without horizontal scroll in Split View

Orientation and Size

  • Landscape layout that doesn't utilize the extra horizontal space effectively
  • Portrait layout with excessively wide content requiring horizontal scroll
  • Missing breakpoints between iPad Mini (768px) and iPad Pro (1024px)
  • Font sizes optimized for desktop that are too small at iPad distances

How to Fix Common iPad Issues

Add Touch Alternatives for Hover Navigation

Since iPadOS Safari requests desktop sites, your hover-dependent navigation must also work on touch. Add click/tap handling alongside hover:

/* CSS: Show dropdown on focus for keyboard/touch */
.nav-item:focus-within .dropdown {
  display: block;
}

/* JS: Toggle dropdown on tap for iPad */
document.querySelectorAll('.nav-item').forEach(item => {
  item.addEventListener('click', (e) => {
    const dropdown = item.querySelector('.dropdown');
    if (dropdown) {
      e.preventDefault();
      dropdown.classList.toggle('open');
    }
  });
});

/* Or use @media (hover: none) to detect touch devices */
@media (hover: none) {
  .dropdown {
    /* Always show on touch devices */
    position: static;
    display: block;
  }
}

Handle Split View Breakpoints

Add breakpoints that handle the intermediate widths iPad Split View creates:

/* Standard breakpoints */
@media (max-width: 768px) { /* Mobile */ }
@media (min-width: 769px) and (max-width: 1024px) { /* Tablet */ }

/* Add Split View aware breakpoints */
/* iPad Pro in 50% Split View = ~512px */
@media (min-width: 500px) and (max-width: 560px) {
  .sidebar { display: none; }
  .main-content { width: 100%; }
}

/* iPad Air in 50% Split View = ~410px */
@media (max-width: 430px) {
  /* Treat like mobile */
  .grid { grid-template-columns: 1fr; }
}

Detect Touch Capability for iPad

Use CSS media queries to detect hover capability and adjust interactions for touch-primary devices like iPad:

/* Apply hover styles only to true pointer devices */
@media (hover: hover) and (pointer: fine) {
  .card:hover {
    transform: translateY(-4px);
    box-shadow: 0 8px 24px rgba(0,0,0,0.12);
  }

  .dropdown:hover .menu {
    display: block;
  }
}

/* Touch-specific styles for iPad */
@media (hover: none) and (pointer: coarse) {
  .card {
    /* Always show "active" state without hover */
    border: 1px solid var(--border-color);
  }

  button {
    /* Larger touch targets */
    min-height: 48px;
    padding: 12px 20px;
  }
}

Common Use Cases

  • Testing web apps and SaaS dashboards used on iPad in professional settings
  • Verifying e-commerce checkout flows on iPad
  • Testing media-rich content sites used for reading on iPad
  • Checking Split View compatibility for productivity apps
  • Verifying that desktop navigation works with touch on iPadOS

Pro Tip

Test your site with Safari's desktop mode explicitly enabled on an iPad (or simulated). Many developers only test at iPad pixel dimensions in DevTools but miss the desktop-mode-on-touch context that real iPad users experience in iPadOS Safari.

Frequently Asked Questions

What are the iPad screen sizes I should test?+
Key iPad viewports are: 768x1024px (iPad Mini portrait), 810x1080px (iPad 10th gen portrait), 820x1180px (iPad Air portrait), 1024x1366px (iPad Pro 11-inch portrait), and 1024x1366px (iPad Pro 13-inch landscape). Always test both portrait and landscape for each model you support, as the layout differences are significant.
Why does my website show the desktop version on iPad?+
Since iPadOS 13, Safari on iPad automatically requests the desktop version of websites. This is Apple's intentional decision to make iPad feel more like a computer. You cannot reliably prevent this with user-agent detection. Instead, design your desktop layout to work with touch input so it functions well when displayed on iPad.
How do I test iPad Split View compatibility?+
Test your website at exactly 50% of each iPad width: 384px (iPad Mini), 405px (iPad), 410px (iPad Air), and 512px (iPad Pro). These are the approximate widths your site appears at in Split View. Pay special attention to navigation, sidebars, and data tables at these intermediate widths — they're the most likely to break.
Should I use CSS media queries or JavaScript to detect iPad?+
Always prefer CSS media queries over JavaScript device detection. Media queries based on viewport width and hover capability are more reliable and maintainable than user-agent sniffing. Use @media (hover: none) and (pointer: coarse) to target touch-primary devices like iPad without hardcoding specific device names or dimensions.
Is iPad usage significant enough to optimize for?+
Yes, particularly for certain content types. News and media sites, e-commerce, productivity tools, and educational content all see above-average iPad usage. iPad users also tend to have longer session durations and higher conversion rates. For B2B SaaS and professional tools, iPad is often a primary work device — making iPad optimization essential, not optional.

Other Responsive Checkers