Screen Resolution Simulator

The Screen Resolution Simulator previews any public URL at common mobile, tablet, laptop, and desktop viewport sizes. Enter a URL, click Check Resolution, and view how the page renders across the device dimensions your visitors actually use — without switching physical devices, manually resizing a browser window, or opening developer tools. Identify layout breakdowns, navigation failures, typography problems, and content overflow before users encounter them.

Responsive design is now the baseline expectation for any website. Google's mobile-first indexing means the mobile version of a page is the primary version used for crawling and ranking. A layout that works correctly on the developer's desktop monitor but breaks at 375px or 768px loses both users and search visibility. The resolution simulator gives any team member — developer, designer, content editor, or SEO analyst — the ability to check layout across devices from a browser tab, with no setup required.

How to use the Screen Resolution Simulator

1. Enter the full URL of the page you want to test — include https://. Use the specific page URL, not just the domain root.

2. Click Check Resolution to open the simulator view.

3. Select a device category or resolution preset — mobile, tablet, laptop, desktop — to preview the page at that viewport width.

4. Review the rendered layout: navigation behaviour, text legibility, image scaling, grid column counts, form element sizing, and whether any content overflows horizontally.

5. Note any issues found at specific viewport widths. Cross-reference with the CSS breakpoints table below to understand which media query range the issue falls into.

6. Fix the identified CSS or layout issues, deploy the changes, and rerun the simulator at the affected viewport size to confirm the fix did not introduce new issues at other widths.

CSS pixels vs physical pixels — what viewport size means

Screen resolution simulators work in CSS pixels, not physical pixels. This distinction matters because modern high-density screens (Retina, AMOLED) have a device pixel ratio (DPR) greater than 1 — typically 2× or 3× on mobile devices. A phone with a 1170×2532 physical pixel display and a 3× device pixel ratio has a CSS viewport of 390×844px. CSS and responsive layout rules operate in CSS pixels, not physical pixels.

This is why responsive CSS breakpoints are defined at values like 375px, 768px, and 1280px — these are CSS pixel widths, which correspond to the logical viewport that the browser's layout engine uses. When testing responsive behaviour, always work with CSS pixel viewport dimensions, not the physical resolution printed on a device's spec sheet.

A common source of confusion: a device marketed as having a '1080p' or '2K' screen may have a CSS viewport of only 390–430px because its device pixel ratio is 3×. When you see the stat '60% of your traffic is on mobile' in Google Analytics, those visitors are rendering your page at CSS widths of 320–430px — not at 1080px. Design and test for CSS pixel widths, not marketing resolution specifications.

Common device viewport widths — reference table

The table below shows the CSS viewport widths that correspond to the most common device categories in use today. Use these as the target dimensions when testing with the simulator.

CSS breakpoints — Bootstrap 5 and Tailwind CSS reference

CSS media queries define breakpoints — the viewport widths at which a layout changes. The two most widely used CSS frameworks define breakpoints at the following widths. Understanding where your layout's breakpoints fall helps you know exactly which simulator width to test when investigating a reported layout issue.

The 768px breakpoint (Bootstrap's md, Tailwind's md) is the most commonly tested and most commonly broken breakpoint on content websites. It sits at the boundary between mobile and tablet layouts — where navigation transitions from hamburger to horizontal, single-column layouts gain sidebars, and grid columns expand from one to two or three. A layout that passes at 375px (mobile) and 1440px (desktop) but has never been tested at exactly 768px frequently has issues at this critical transition point. Always include 768px as an explicit test width.

What to check at each viewport size

Screen Resolution Simulator vs browser DevTools — when to use each

Browser DevTools responsive mode and the Screen Resolution Simulator are complementary, not competing tools. DevTools is for active development — you need access to the browser on the same machine, and you can edit CSS live. The simulator is for reviewing live sites externally — checking a competitor's layout at mobile widths, reviewing a client's site before a meeting, or giving a non-developer team member (content editor, marketing manager, SEO analyst) the ability to check cross-device layout without opening DevTools. For final QA before launch, both tools should be used alongside testing on at least one physical mobile device.

Which pages to test and in what order

• Homepage — first impression for all new visitors; navigation, hero section, and above-the-fold content must work at every viewport width.

• Top organic landing pages — identified from Google Search Console Performance report sorted by clicks. These are the pages with the most to lose from layout failures.

• Category and hub pages — typically use custom grid layouts and filtering components that behave differently from article pages. Grid column transitions at tablet widths are a common failure point.

• Conversion pages — checkout, contact forms, pricing pages, and subscription sign-up flows. Form element sizing and button tap targets on mobile directly affect conversion rates.

• Pages after any CSS, theme, or plugin update — layout changes can have unintended side effects at specific viewport widths that are not visible in the viewport the change was made in.

• Pages with embedded third-party content — maps, video players, pricing widgets, and comparison tables from third-party providers frequently fail at narrow viewport widths because the embed is built to a fixed width.

Usage limits

Related tools

• Mobile Friendly Test — check mobile usability signals including viewport configuration, tap-target sizing, font size, and content overflow. The mobile friendly test analyses the page's HTML and CSS rules; the resolution simulator shows you what those rules produce visually at specific viewport widths. Use both together for a complete mobile review.

• Get HTTP Headers — verify server response headers after layout changes, including cache headers that may cause browsers and CDNs to serve an outdated version of your CSS. If layout changes are not appearing in the simulator, a CDN cache issue may be serving the old stylesheet.

• Website SEO Report — full on-page SEO analysis. Combine with viewport testing for a complete pre-launch audit: SEO signals (title, meta description, headings, canonical) plus visual layout across device sizes.

Frequently asked questions

What is a screen resolution simulator and how does it work?

A screen resolution simulator previews a webpage as it would appear at a specific viewport width, simulating how the page renders on devices with different screen sizes. It loads the target URL and constrains the rendering to the selected viewport dimensions — the same width in CSS pixels that the device's browser would use. This reveals how the page's responsive CSS rules behave at that width: which layout columns appear, whether the navigation collapses to a hamburger menu, whether images scale correctly, and whether any elements overflow horizontally. It works on any publicly accessible URL without requiring access to the site's code or server.

What is the difference between screen resolution and viewport size?

Screen resolution is the physical pixel count of a display — for example, 2532×1170 physical pixels on an iPhone 15. Viewport size is the CSS pixel width that the browser's layout engine uses for responsive design calculations — for example, 390px CSS pixels for that same iPhone 15. The relationship between them is the device pixel ratio (DPR): physical pixels divided by DPR equals CSS pixels. A 3× DPR device with 1170 physical pixels wide has a 390px CSS viewport. Responsive CSS media queries and layout breakpoints operate in CSS pixels. When testing responsive behaviour, always use CSS pixel viewport widths — not the physical screen resolution from the device's product listing.

Why does my site look fine on my desktop but broken on mobile?

The most common causes are: fixed-width CSS values (setting a container to width: 900px rather than max-width: 900px or 100%), images without max-width: 100% that overflow their container at narrow widths, CSS hover states used for navigation dropdowns that do not work on touchscreens, viewport meta tag missing (causing the browser to render at 980px desktop width and scale down), and responsive breakpoints that were never tested at the specific mobile width where the issue appears. Desktop-first development — building at a wide viewport and adding media queries to reduce — is more likely to produce mobile layout failures than mobile-first development (building the narrow layout first and progressively enhancing for wider viewports).

What viewport widths should I test as a minimum?

A minimum testing set that covers the majority of real-world device usage: 375px (standard mobile — iPhone SE, widely used as the mobile design target), 390px (dominant mobile — iPhone 14/15, the most common mobile viewport in current analytics data), 768px (tablet portrait — the most critical breakpoint transition for most layouts), 1024px (tablet landscape and small laptop), 1280px (small laptop — often overlooked when designing on large monitors), and 1440px (standard desktop). If analytics show significant traffic from specific devices not covered by these widths, add those widths to the testing set. Check Google Analytics Audience → Technology → Screen Resolution for the actual viewport distribution of your visitors.

Is the simulator the same as testing on a real device?

No — a simulator and a real device test different things and both are valuable. The simulator is excellent for checking CSS layout, responsive breakpoints, visual hierarchy, content overflow, and approximate typography sizing across viewport widths, quickly, without needing physical devices. A real device test adds what the simulator cannot: actual touch behaviour (scroll momentum, swipe gestures, tap accuracy on physical glass), browser-specific rendering quirks (Safari on iOS renders some CSS differently from Chrome on Android), performance under real network conditions on a mobile data connection, and the physical experience of holding and using the page. For final QA before a site launch or major update, both simulator testing and physical device testing on at least one iOS and one Android device are recommended.

What does 'horizontal scrolling' on mobile indicate?

Horizontal scrolling on mobile — where users can swipe left or right on a page that should fill the screen width — almost always indicates that at least one element on the page is wider than the viewport. Common causes: an image with a fixed pixel width wider than the viewport (fix: add max-width: 100% to all img elements), a container with a fixed pixel width rather than a percentage or max-width, an absolutely positioned element that extends beyond the viewport edge, or a table with fixed column widths that cannot compress below a certain total width. In Chrome DevTools, the Rendering tab has an option to highlight layout shifts — this can help identify which specific element is causing the overflow. In the simulator, horizontal overflow is visible as a scrollbar appearing below the page content.

Should I test staging environments or only live sites?

The Screen Resolution Simulator works with any publicly accessible URL — it cannot access URLs that require a login, are on a private network, or are blocked to external requests. For staging environments, if the staging URL is publicly accessible (a subdomain like staging.example.com without authentication), the simulator can preview it directly. For password-protected staging, localhost environments, or internal network URLs, use browser DevTools responsive mode instead — it can access any URL the local browser can reach. The simulator is particularly useful for live site review after deployment, for reviewing competitor sites, or for sharing cross-device preview screenshots with stakeholders who do not have DevTools access.

Is the Screen Resolution Simulator free?

Yes. The simulator is free within the daily usage limits. Guest users can run 25 simulations per day. Registering a free ToolsPiNG account increases the limit to 100 simulations per day — useful when auditing a full site across multiple pages and multiple viewport widths in a single session. For a thorough cross-device audit of a site with 10+ key pages tested at 5+ viewport widths each, the 100-per-day limit accommodates a complete audit in a single session.