Windows Dev Center

Guidelines for supporting multiple screen sizes

Windows and Windows Phone Store apps can run on a variety of devices with different screen sizes and resolutions. Users can also modify the screen's orientation, or, if the app is running on Windows, continuously resize it down to a minimum width or display it beside other apps. Whether a user runs your app on a phone, tablet, laptop, desktop, or PPI device, ensure that its UI looks good and maintains its functionality. Follow these guidelines when designing a UI that adapts to screens of all sizes and orientations.

For specific guidance on adapting a Windows Store app to narrow window sizes, see Guidelines for resizing to narrow layouts.


Your app will likely run on a variety of screen sizes which could range from a small phone screen, to a medium laptop screen, and perhaps even an all-in-one or PPI device screen. Depending on screen size and resolution, the amount of viewable area for your app to take advantage of will vary.

sample app on a tablet device

sample app on a large desktop monitor

The following terms are important for understanding scaling to different screen sizes.


Screen size

The physical size of the screen, in inches. Usually measured on the diagonal.

Screen resolution

The number of pixels the screen supports, in horizontal and vertical dimensions. For example, 1366x768.

Aspect ratio

The shape of the screen as a proportion of width to height. For example, 16:9.


The platform, controls, and templates have all been designed to accommodate different screen sizes, resolutions, and aspect ratios. Although much of your app's layout will automatically adjust to display changes, you must consider your top-level layout, content regions, app navigation, and commands to ensure that they are placed predictably and intuitively on all screens.

The following tables show the most important screen sizes to consider when designing your app.

Fullscreen screen size (effective pixel resolution)Device description
1366x768Tablets, convertibles, and many laptops (16:9 aspect ratio); baseline laptop/desktop resolution
1920x1080Large laptops and devices (16:9 aspect ratio)
2560x1440Very large all-in-one device (16:9 aspect ratio)
1280x800 and 800x1280 Portrait-first small devices (16:10 aspect ratio)
1024x768 and 768x1024Landscape-first small devices (4:3 aspect ratio)
1371x857 and 857x1371Small devices (16:10 aspect ratio)
384x6404.5" phone (15:9 aspect ratio)
400x7114.7" phone (16:9 aspect ratio)
450x8005.5" phone (16:9 aspect ratio)
491x8736" phone (16:9 aspect ratio)


When designing an app to run on Windows, not Windows Phone, consider the screen size available when a user has two apps share the screen, or resizes your app to its minimum width.

Split screen size (effective pixel resolution)Description
672x768Screen split in half on a 1366x768 device
500x768Default minimum size for app; Screen split in half on a 1024x768 device
320x768Minimum size for apps that support 320 pixel minimum width


For scaling recommendations, see Guidelines for scaling to pixel density.

Important fullscreen and split screen window sizes

Dos and don'ts

  • When possible, rely on flexible controls to support content that reflows automatically. Flexible controls include the XAML Grid control, CSS grid, CSS Multi-column layout, and ScrollViewer control. Grid controls, for example, flex specific sections of your UI to fill available space depending on the screen resolution of the display device and assign content to different cells based on available screen space.
  • Design your app layout and controls to adjust and function on screens of the minimum size:
    • Default minimum width for Windows Store apps: 500px.
    • Non-default minimum width for Windows Store apps: 320px.
    • Minimum (not adjustable) for Windows Phone Store apps: 384px (portrait) and 640px (landscape).
  • The UI and controls must be usable at all screen sizes, down to the minimums (listed above). Important controls to consider are:
  • Design your app to effectively use the space on a large screen and to have a layout that reflows automatically. Don't leave large empty spaces.
  • Test that your app works well on the most important device sizes. In addition to testing your app on actual devices, you can use the Microsoft Visual Studio simulator for Windows Store apps to simulate running your app on different physical screen sizes, resolutions, and orientations.
  • Specify a minimum size for all input fields. Minimum sizes ensure that the input fields don't disappear when the user resizes the window.
  • Test that your app's input fields are not occluded by the soft keyboard.
  • Be cautious when using absolute positioning; if used improperly it can prevent your UI from responding to changes in window size and orientation. Rather than hardcoding your layout, use positions computed at runtime to layout your UI.
  • Design for different pixel densities. To learn more, see Guidelines for scaling to pixel density.

Windows Store apps only

  • Ensure that your app is functional down to the default minimum width of 500 pixels. See Guidelines for narrow layouts for specific recommendations.
  • If your app works well at smaller sizes and you want to encourage users to keep your app on the screen, you can support a non-default minimum width of 320 pixels.
  • Make sure that users can continue their current tasks when they resize apps. For example, maintain the current page of the app, state of scroll bars, selection, and focus.
  • Support charms at all screen sizes. Make sure flyouts and panes, are scaled appropriately.
Note   In Windows 8, users could resize apps to only three view states: full screen, snapped, and fill. In Windows 8.1, users can resize apps to any width from full screen down to the minimum width.

Additional usage guidance

Automatic support for orientation changes

Users can rotate their phones, tablets, and monitors. Windows handles both landscape and portrait orientations automatically, as long as your app isn't using a fixed layout. You'll only need to consider how the app's width affect its layout.

See the fixed layout section below for more info on when it might be appropriate to forgo a flexible layout.

Landscape and portrait layouts

Resized app behavior (Windows Store apps only)

If a user has multiple apps on the screen, note these unique UI interactions:

  • If a user invokes the charms, the charms apply to the last app that the user used, regardless of the size of the app or the position of the app on the screen.
  • Between each app on the screen is a handle. Users resize app windows by sliding the handle. The handle also shows which app has focus.
  • If a user grabs the handle between apps and tries to resize an app to a width that is less than the app's minimum width, the app leaves the screen.
  • If a user rotates a device or monitor while multiple apps are on the screen, the apps do not switch orientation.

Fixed layouts

Most apps can use a dynamic layout that adapts to changes in screen size and resolution, and reflows content automatically. But in some cases, your app may require a fixed layout. Apps that aren't content-focused or depend on the integrity of graphics, such as gaming apps, need to use fixed (absolute) layouts. Windows accommodates these apps with a "scale-to-fit" approach that is built into the platform.

If you determine that your app requires a fixed layout that won't automatically adapt to different screen sizes, you can use a scale-to-fit approach to make your fixed layout fill the screen on different screen sizes, as shown in the following images.

Scale to fit for a fixed layout game

To implement the scale to fit approach, do the following:

  • Design your layout for the baseline resolution, for example, 1366x768 pixels (PC/tablet) or 384x640 pixels (phone). This is the layout that will be scaled to the larger screens.
  • Place your fixed content within a ViewBox control (ViewBox in JavaScript and HTML or Viewbox in C#/VB/C++ and XAML). The ViewBox control scales a fixed layout to fit the screen.
  • Ensure that the ViewBox control is sized to 100% width and height.
  • Define the fixed size properties of the ViewBox to the fixed pixel sizes of your layout (for example, 1366x768 or 384x640).
  • Choose a letterboxing color. Fixed controls do not dynamically change in response to aspect ratio or screen size changes, so the scale-to-fit technique automatically centers and letterboxes (horizontally, or vertically) your app’s content. Your top-level app layout's color determines the color of the letterbox bars. We recommend choosing a dark color like black that blends in with the hardware, a neutral color like grey that looks intentional, or a color that matches your app content color.
  • Provide vector or high-resolution assets. The scale-to-fit technique scales your application to varying sizes up to 180% (for Windows) or 280% (for Windows Phone) of the design size for your app on a large desktop monitor. Vector assets like Scalable Vector Graphics (SVG), Extensible Application Markup Language (XAML), or design primitives scale without scaling artifacts or blurriness. If raster assets (such as bitmap images) are required, provide MRT assets.

    The following images demonstrate how scalar images (right) degrade when scaled up in size compared to vector images (left).

    Resizing vector and scalar images
  • Don't place adaptive controls in a ViewBox control.

For additional recommendations on scaling, see Guidelines for scaling to pixel density.

Related topics

For designers
Guidelines for scaling to pixel density
Guidelines for resizing to narrow layouts
For developers (HTML)
Choosing a layout
Quickstart: Defining app layouts
Quickstart: Designing apps for different window sizes
Guidelines for scaling to pixel density
Guidelines for resizing to narrow layouts
For developers (XAML)
Quickstart: Defining layouts
Quickstart: Designing apps for different window sizes
Guidelines for scaling to pixel density
Guidelines for resizing to narrow layouts
Layout for windows that resize to 320 pixel width sample
Layout for windows that are taller than wide sample



© 2015 Microsoft