How to Test Websites on Foldable Phones

Test a foldable website as a set of screen states, not as one device size. Start with responsive widths in Chrome DevTools, exercise folded and unfolded states in DevTools or Android Emulator, then check high-risk pages and user journeys on a real foldable or a real-device service. Cover orientation changes, navigation, forms, menus, dialogs, scrolling, and any layout intended for book or tabletop postures. Check that a hinge or segment boundary does not obscure important content. Keep core behavior usable when fold-specific browser APIs are unavailable.

A foldable’s usable viewport depends on its device, browser, display settings, posture, and available window size. Avoid designing around one reported model dimension or treating the expanded screen as merely a stretched phone. Prefer content-driven breakpoints and test the ranges your users actually encounter.

1. Establish a responsive baseline

Begin with the normal responsive web workflow. In Chrome, open the page and select Toggle device toolbar in DevTools. Use responsive mode to enter widths around your CSS breakpoints; rotate the viewport and inspect media queries. Device Mode supports simulated dimensions, orientation, and—on supported emulated devices—folded posture and dual-screen controls. Chrome DevTools Device Mode documentation

1. Test just below, at, and just above each breakpoint that affects navigation, columns, typography, or controls.
2. Check a narrow exterior-screen range and a wider interior-screen range. Include intermediate widths, since users may resize a browser window or use split-screen.
3. Look for horizontal overflow, clipped content, overlapping controls, overly long lines, and text or buttons that become difficult to use.
4. Check both portrait and landscape orientations. Repeat after rotating while the page is already open.

Do not copy a single model’s reported CSS viewport into a universal breakpoint. Use the width at which your content needs to change, and verify the relevant ranges in emulation and on your target devices.

2. Exercise folded, unfolded, and dual-screen states

In DevTools, select a suitable emulated device when available. The device toolbar can toggle dual-screen mode on supported devices and switch posture between Continuous and Folded. Names and available controls can vary by Chrome version and device profile. Chrome’s device posture and dual-screen controls

For a repeatable Android check, create a foldable virtual device in Android Studio’s Device Manager, start it in Android Emulator, open your site in its browser, and use the emulator’s Fold and Unfold controls. The emulator documentation describes these controls for foldable devices. Android Emulator documentation

1. Load a representative page in the compact state and complete a core task.
2. Unfold the device while the page is open. Check that the page reflows without a reload, loses no form data, and keeps the user’s place where reasonable.
3. Fold it again. Confirm that navigation, menus, dialogs, and sticky controls still fit and remain reachable.
4. Repeat with a fresh load in each state. A page may behave differently when its initial viewport is compact versus when it changes after load.
5. If the emulated profile supports multiple screens, test single-screen and dual-screen modes separately.

Emulation is useful for rapid, repeatable layout checks. It does not establish that every browser, touch interaction, device configuration, or physical hinge behaves like the simulation.

3. Inspect content at the hinge and segment boundary

When a device exposes distinct screen segments or a visible hinge area, inspect what lands at the boundary. Check headings, paragraphs, images, video, dialog edges, menus, and controls. Avoid placing essential text or a primary action where a hinge, seam, or gap makes it hard to read or tap.

If the design intentionally uses two panes, make each pane understandable on its own and verify the same page on a continuous screen. A master-detail layout, for example, should still have a sensible single-column or stacked fallback when there is no useful split.

Chrome’s Foldable APIs article explains viewport segments as logical regions and shows the design context for fold-aware layouts. It describes Device Posture and Viewport Segments APIs as an origin trial from Chrome 125 through 128. Treat that article as background for the experiment, not as evidence of current cross-browser support. Keep essential layout and navigation functional without these APIs. Chrome’s Foldable APIs origin-trial article

4. Test real website journeys in each useful posture

Translate book and tabletop postures into browser-page checks that matter to your site. Android’s foldable app quality guidance calls out those postures and checking that UI elements move to useful positions. These are useful test prompts for websites; app-specific requirements do not automatically apply to an ordinary web page. Android foldable quality guidance

• Navigation: open and close the menu, follow a link, use browser back, and check that the active page and scroll position make sense after a posture change.
• Forms and sign-in: enter data, open the software keyboard, move between fields, submit, and verify validation messages are visible and associated with the right fields.
• Dialogs and overlays: open cookie notices, consent panels, search overlays, and confirmation dialogs. Check that they fit, can be dismissed, and do not trap controls behind the hinge or keyboard.
• Long-form reading: inspect line length, paragraph flow, images, sticky headers, and scrolling near the segment boundary. Ensure expanded width does not create difficult-to-read lines.
• Media and interactive tools: test playback controls, charts, editors, maps, and drag or touch interactions. In tabletop-like use, confirm controls remain practical in the visible region.
• Responsive state changes: change posture or orientation with a menu, form, or dialog open. Check for stale positions, stranded overlays, lost input, and unexpected jumps.

For native Android apps, Samsung also discusses continuity, multi-active window, and Flex mode. Treat those as prompts only where your site or embedded web experience actually depends on those behaviors. Samsung foldable testing guidance

5. Validate the highest-risk pages on real devices

After emulator and DevTools checks, test critical flows on a physical foldable or a real-device testing service where practical. Prioritize pages where layout failures block a task: sign-in, checkout, account settings, forms, media, and interactive tools. Android’s guidance points to Firebase Test Lab or a similar device farm for access to real devices, including foldables. Check the service’s current device catalog and terms before depending on it. Android guidance on foldable testing

A single handset validates one device and browser combination. Use your own audience data to choose target models and browsers, then keep a small, repeatable smoke-test list for the journeys that matter most.

6. Capture page states for review

Screenshots help compare a page before and after a layout change, document a clipped control, or share a bug report. Capture the same URL and viewport state consistently, and record the device profile, browser, orientation, posture, and steps that produced the issue. A screenshot records visible output; it does not replace touch, keyboard, navigation, or real-device checks.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. Use it to capture a page for visual review; use DevTools, an emulator, or real hardware to change foldable posture and verify interactive behavior. See the ScreenshotNeo API documentation.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as image:
    image.write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await require('node:fs/promises').writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Replace the example URL with a publicly reachable page. See the docs for request options and configuration. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000.

Sign up free for 1,000 screenshots a month, with no card required.

Common problems and fixes

Symptom	Likely cause	What to check
Content is cut off on the compact display	A breakpoint, fixed width, or minimum width assumes a wider viewport.	Test around the breakpoint; inspect wide fixed elements, tables, and long unbroken strings. Allow wrapping or provide a deliberate compact layout.
Expanded state looks like a blown-up phone page	The layout has no useful intermediate or wide-screen arrangement.	Choose breakpoints based on content needs. Revisit line length, navigation, columns, and image sizing at expanded widths.
Text or a button is hard to use at the hinge	Important content crosses a segment boundary or control placement assumes one uninterrupted area.	Inspect segment boundaries in supported emulation and on hardware. Reposition the content, or use a layout that works without a hinge-aware API.
Page jumps or loses a form after unfolding	A resize handler rebuilds content, resets state, or changes scroll position.	Change posture while the form is active. Preserve input state and avoid unnecessary remounts; restore a sensible scroll position after layout changes.
DevTools has no fold controls for the selected device	The selected profile or current DevTools build does not expose those controls.	Choose a supported emulated device, update the browser if appropriate, or use Android Emulator. Verify the behavior on hardware for important flows.
Emulator passes but a physical phone fails	Emulation does not reproduce every browser, touch, hinge, or device behavior.	Record model, browser, orientation, posture, and reproduction steps. Add that configuration to the regression smoke-test list.
A fold-specific API is undefined or behaves differently	Support is experimental or unavailable in the browser being tested.	Feature-detect any optional enhancement and retain a complete responsive fallback. Do not gate basic navigation or content on the API.

Performance, reliability, and cost

• Keep the fast loop local: use DevTools and an emulator for broad width and state iteration, then reserve physical-device checks for representative, high-risk journeys.
• Make runs repeatable: document URL, browser, device profile, orientation, posture, viewport, and interaction steps. Use the same smoke-test pages after layout changes.
• Do not infer reliability from a screenshot: a static capture can reveal visual defects, but it cannot prove that a menu is tappable, a form submits, or layout survives rotation and folding.
• Choose hardware deliberately: a physical device has purchase or access cost, while device-farm availability and pricing vary by provider. Confirm current options directly with the provider.
• Keep APIs optional: experimental fold-aware browser features can change in availability. Standard responsive behavior should remain useful without them.

Foldable website testing checklist

• Compact exterior and expanded interior widths checked, including widths around relevant breakpoints.
• Portrait and landscape checked, including rotation while the page is open.
• Folded, unfolded, and dual-screen states checked where the device supports them.
• No unintended horizontal scrolling, clipped controls, unreadable text, or hinge-obscured content.
• Navigation, forms, keyboard, dialogs, scrolling, and core task flows checked in relevant states.
• State and scroll behavior checked when posture changes during interaction.
• Critical journeys verified on a physical foldable or suitable real-device service.
• Basic content and navigation still work without fold-specific browser APIs.

FAQ

Do I need to buy a foldable phone to start testing?

No. DevTools and Android Emulator cover many responsive sizes and fold states. Use hardware or a real-device service for final checks on the browsers and devices important to your audience.

Should I use a Galaxy Z Fold viewport as my breakpoint?

Use it as one test case, not a universal breakpoint. Available viewport size varies, and content-driven breakpoints are more resilient.

Does a screenshot prove a foldable layout works?

No. It documents pixels at one moment. You still need to interact with the page, change orientation or posture, and verify important behavior on the target browser or device.

Should my site require the Viewport Segments API?

No. The cited Chrome article describes an origin trial that ran from Chrome 125 through 128. Do not assume current cross-browser support; make fold-aware behavior optional and preserve a responsive fallback.