Website Screen Resolution Test Free Tool

Enter a URL

About Website Screen Resolution Test

What This Tool Actually Does

The Website Screen Resolution Test on limitlessreferrals.info does one specific thing. It opens any URL you give it in a new browser window at one of eight fixed sizes. That's the whole mechanism. There is no server involved, no screenshot taken, no iframe embedded on the page, and no preview pane that updates as you move a slider. You type a web address, you pick a width and height from eight radio buttons, and you click the button. Your browser then pops open a real window at that size and loads the site inside it.

The viewport size directly affects how the tool behaves. Because the tool creates an actual browser window on your own machine, the page you see is running in your own browser session. Your cookies are there. Your logins are there. Your browser extensions are loaded. JavaScript executes exactly as it would if you had opened the site in a normal tab. Sites that refuse to load inside iframes, the kind that send an X-Frame-Options header or a Content Security Policy directive, open without complaint here. The tool uses a plain window with a chosen outer size.

The eight sizes are fixed. You cannot type a custom width or height. The presets are 160x160, 320x320, 640x480, 800x600, 1024x768, 1366x768, 1152x864, and 1600x1200. The default selection, the one that is pre-checked when the page loads, is 1024x768. That default tells you something about the age of the preset list. A 1024x768 viewport was the standard web design target in the early 2000s. Modern desktop monitors are wider, and modern phones are far smaller in CSS pixels than 320x320 in one dimension. The tool does not include a single phone preset or a single modern laptop preset beyond 1366x768.

The entire check runs in your browser. The form never submits to the server. The JavaScript function that does the work, which lives in a file called screen_simulator.js on the site, reads the URL field, reads the checked radio button, and calls window.open() with the width and height you chose. If you leave the URL field empty, you get a popup alert that says "Enter a URL". If you type a URL without a protocol, the script prepends http:// for you. Everything else is standard browser behavior.

You should understand what this tool is before you use it, because it is easy to overread the name. A screen resolution test sounds like it might emulate a device. The tool resizes a window. That distinction drives everything else about what the tool can tell you, what it can't, and why the old description on this page was wrong.

How to Use This Tool

1. Open the tool page. Find the input box above this article. The page has one text field for a URL, eight radio buttons for resolution, and a button. Nothing else is required.
2. Enter a web address. Type the full URL of the site you want to test. If you leave off the http:// or https:// prefix, the tool adds http:// for you automatically.
3. Pick a screen size. Select one of the eight radio buttons. The default is 1024x768, so if you want that size, you don't need to click anything.
4. Click the button to run the test. Your browser will attempt to open a new window at the chosen width and height and load the URL you entered.
5. Allow popups if your browser asks. Modern browsers block popup windows by default. You will see a popup blocked icon in the address bar. Click it and allow popups for this site, then run the test again.
6. Inspect the window that opens. Look at the layout, the navigation, the images, and the text at that size. Close the window when you're done and repeat with a different preset.

That's the entire workflow. There is no export, no report, no side-by-side comparison, and no history of your tests. You run one size at a time, you look at the result, and you close the window. A quick check of how a page behaves at the default preset takes about twenty seconds. For a full responsive audit across phones, tablets, and desktops, you'll want other tools. Chrome DevTools and Firefox's responsive design mode both offer deeper control.

The Eight Presets and What They Represent

The radio buttons on this tool encode a particular moment in display technology. The full set of presets is listed in the table below.

The list has a clear bias toward 4:3 aspect ratio screens. Six of the eight presets are 4:3 or nearly square. Only 1366x768 is a widescreen format, and it's the one that matches the most common laptop resolution in the world. The missing sizes tell the real story of modern web design. There is no 375x812, which is the CSS pixel size of an iPhone X and later models. There is no 390x844, the size of the iPhone 12 through 15 generation. There is no 768x1024, the portrait iPad size. There is no 1920x1080, the resolution of nearly every desktop monitor sold in the last fifteen years.

The preset list is a museum of old desktop targets, with one modern laptop size added. If you test a site at 1024x768 and 1366x768, you cover the two most important desktop widths of the last two decades. If you need phone or tablet sizes, you'll need to use the browser's developer tools. Those tools offer a different set of capabilities, and the comparison sections describe those differences in detail.

What Happens When You Click the Button

The JavaScript behind this tool is short and direct. It reads the URL field. If the field is empty, it shows an error dialog that says "Enter a URL". If the URL lacks a protocol, it adds http:// to the front. Then it calls window.open() with a set of window features. The feature string includes toolbar=no, status=yes, scrollbars=yes, location=yes, menubar=no, and directories=yes, along with the width and height you selected.

Those feature flags are largely ignored by modern browsers. Chrome, Firefox, and Safari all made decisions years ago to stop honoring most of the window features that window.open() accepts. The toolbar=no flag doesn't hide the toolbar in Chrome. The menubar=no flag doesn't hide the menu in Firefox. What the browsers do honor, within limits, is the width and height. So the practical effect of clicking the button is that a new window opens at approximately the size you chose.

The word "approximately" carries real weight. The width and height you pass to window.open() set the outer window size in most browsers. The outer size includes the browser chrome, the tab bar, the address bar, the scrollbars, and any other UI elements. The actual viewport, the area where the web page renders, is smaller. A window set to 1366x768 might have a viewport of only 1340x700 or so, depending on the operating system and browser. If you're testing a site that uses a media query at exactly 1366 pixels, you might see the desktop layout when you expected the laptop layout, simply because the viewport falls just below the breakpoint.

There's another clamp at play. Browsers refuse to open a window larger than the physical screen. If you're on a laptop with a 1366x768 display and you select the 1600x1200 preset, the browser will not create a window that big. It will open a window as large as the screen allows, often maximized or nearly so. The tool can't force a window beyond your monitor's resolution. This is a hard limit of the browser.

Popup blockers are the other obstacle. Because the window is opened by JavaScript after a user click, most browsers will allow it. But some extensions and some browser configurations are aggressive about blocking any window.open() call. If nothing happens when you click the button, check the address bar for a popup blocked icon. You'll need to allow popups for limitlessreferrals.info and try again.

Correcting the Old Description of This Tool

The previous version of this page described the tool in ways that don't match its actual behavior. This article exists in part to correct that record. The old copy claimed the tool used a "test frame". The tool opens a new browser window via window.open(). There is no frame element anywhere in the page's code, no <iframe>, no embedded preview. The old page also warned that some sites wouldn't load "inside the test frame" and that you'd see a blank area instead. That warning was fiction. Since the tool never used a frame, there was never a frame-blocking problem to begin with. Sites that send X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN refuse to render inside iframes, but they load perfectly fine in a real window.

The old copy also said that "a login required page can't be tested". That was wrong in two ways. First, the tool doesn't attempt to log you in or out of anything. Second, because the tool opens a real window in your own browser, your existing login cookies are sent along with the request. If you're already logged into a service in your browser, the site will open in the popup window with your session intact. If you're not logged in, you'll see the login page, and you can log in right there in the popup. Either way, a login-protected page can be tested. The old claim appears to have been written by someone who assumed the tool ran in a sandboxed frame with no cookies. It doesn't.

The old description also implied device emulation. It suggested that choosing a small size like 320x320 would show you how the site looks on a phone. That implication was misleading. A 320x320 window on a desktop is a small desktop window. It sends a desktop user agent, it has a desktop device pixel ratio, it has no touch events, and it has a mouse cursor. The site's JavaScript sees a desktop browser with a narrow viewport. Many responsive sites will switch to their mobile layout at that width, because they use CSS media queries based on viewport width alone. But any site that checks the user agent, or that serves different HTML to phones based on server-side detection, will show you the desktop version squeezed into a small window.

What a Window Size Test Can Tell You

A real window at a chosen size is a legitimate testing method, and it has one major advantage over emulation. It runs the actual site in a real browser engine with real network conditions, real cookies, and real JavaScript. There is no approximation in the rendering. What you see in that popup window is exactly what a visitor with a desktop browser at that window size would see.

This makes the tool useful for a specific class of checks. If your site uses CSS media queries to rearrange the layout at certain widths, you can verify that the breakpoints fire correctly. Set the window to 1024x768 and confirm that the desktop navigation appears. Set it to 800x600 and confirm that the layout collapses to a narrower arrangement. Set it to 320x320 and see whether your CSS switches to something resembling a mobile layout. The tool is a quick way to answer the question "what does my site look like when the viewport is this wide?"

It's also useful for checking fixed-width layouts. If your site has a container that's 1200 pixels wide and you want to see how much horizontal scrolling a visitor at the default preset will experience, this tool shows you directly. You'll see the horizontal scrollbar appear, and you'll know the layout is too wide for that viewport. The same check works for elements that overflow, images that don't scale, and text that gets cut off.

Because the window uses your real browser profile, you can test pages that require authentication. Log into your site's admin area in a normal tab, then run the tool on a URL that's behind the login. The popup window will have your session cookie, and the page will load as it would for you. This is something that many online testing tools can't do, because they load pages from their own servers without your cookies.

What a Window Size Test Cannot Tell You

The limits of this approach are just as important as its strengths. A resized window is a desktop browser window with a narrow viewport. It doesn't change the user agent string, so the site's server sees a desktop browser. It doesn't change the device pixel ratio, so a 320x320 window on a high-DPI display still renders at the desktop's pixel density, which means text and images will look different from how they look on a phone with a similar CSS width. It doesn't emulate touch events, so any interaction that depends on touch, like swipe gestures or tap targets, won't behave as it would on a phone. It doesn't simulate the mobile viewport meta tag behavior that phones apply. A 320x320 window is a narrow desktop window, and you should treat it that way.

The tool also can't tell you anything about physical screen resolution in the sense that a visitor's monitor is 1920x1080 or 2560x1440. The window size you choose is independent of the visitor's actual screen resolution. A site might look fine in a 1366x768 window but terrible on a 1366x768 physical screen with a browser that isn't maximized, because the viewport is even smaller. The tool tests the window. Your monitor's native resolution stays out of the equation.

There's also the matter of browser differences. The tool opens the window in whatever browser you're using. If you test in Chrome, you're seeing Chrome's rendering. You're not seeing Firefox's, Safari's, or Edge's. Cross-browser differences in CSS support, JavaScript behavior, and font rendering won't show up. You'd need to run the test in each browser separately to get a full picture.

Finally, the tool can't show you the site at a size larger than your physical screen. If you're on a 1366x768 laptop, you can't test the 1600x1200 preset meaningfully. The browser will clamp the window to fit your screen. To test large viewports, you'd need a larger monitor or a different tool.

Comparing With Chrome DevTools Device Mode

The most direct comparison for this tool is Chrome's built-in device mode, which lives in the Developer Tools. You open DevTools with F12 or Ctrl+Shift+I, click the device toolbar icon, and you get a responsive viewport that you can drag to any size. You can also select from a list of preset devices, including iPhones, iPads, and Android phones. This is the tool most web developers actually use for responsive testing.

Device mode goes far beyond window resizing. It emulates the user agent string of the selected device. It emulates the device pixel ratio, so a page on an iPhone preset renders at the correct CSS pixel dimensions with the correct pixel density. It can emulate touch events, so hover states don't apply and tap targets are tested properly. It can even simulate network conditions like slow 3G. None of that is available in the screen resolution test tool.

But device mode has its own limitations. It runs inside a DevTools panel, with the viewport embedded in the browser window. Some sites detect the DevTools viewport and behave differently, though this is rare. More importantly, device mode does not change your real cookies or logins. If you're testing a page behind a login, you'll need to log in within the device mode viewport, which can be awkward. The screen resolution test tool, because it opens a real window, carries your existing session automatically.

Device mode is also a simulation. It emulates the iPhone's user agent and pixel ratio, but it doesn't run iOS Safari. It runs Chrome's rendering engine with iPhone-like parameters. Most of the time this is close enough, but subtle differences between Chrome's mobile rendering and Safari's mobile rendering can slip through. The screen resolution test tool doesn't pretend to be a phone, so it never gives you false confidence about mobile compatibility.

A quick comparison of the two approaches appears in the table below.

These tools complement each other. Use the screen resolution test when you need a quick look at a real window with your real session. Use device mode when you need to emulate a specific phone or test many custom widths.

Comparing With Real Devices

No software tool fully replaces testing on actual hardware. A real iPhone runs Safari with WebKit, has a physical touch screen, has a specific pixel density, and connects to the network with real mobile conditions. A real Android phone runs Chrome or another browser with its own quirks. The only way to know for certain how a site feels on a phone is to hold a phone and use the site.

The screen resolution test tool doesn't try to replace real devices. It doesn't claim to. But the gap deserves explicit attention. When you open a site in a 320x320 window on your desktop, you're seeing the site's CSS respond to a narrow viewport. You're not seeing how the site handles the lack of a hover state, how big the tap targets are for a finger, how the viewport meta tag interacts with the physical pixel ratio, or how the site performs on a mobile network. Those factors are invisible to a desktop window.

Real device testing also catches issues that emulation misses. Font rendering differs between desktop and mobile operating systems. Mobile browsers handle text size adjustment differently. The address bar in mobile browsers takes up space that affects viewport height. Scroll behavior, momentum, and overscroll effects are all different. A window on a desktop with a mouse wheel doesn't replicate any of that.

The practical advice is to use all three layers. Start with the screen resolution test tool for a fast check of your layout at common desktop widths. Move to Chrome DevTools device mode to check specific phone models and to emulate touch and pixel ratio. Finish with a real device, ideally both an iPhone and an Android phone, to catch the things that only hardware can reveal. This layered approach is standard practice in web development, and it's the only way to get reasonable confidence about responsive design.

The Missing Sizes and Why They Matter

The preset list stops at 1600x1200. There is no 1920x1080, which has been the standard desktop resolution since around 2010. There is no 2560x1440, common on larger monitors and many laptops. There is no ultrawide size. For a tool whose name includes the word "resolution", the absence of the most common modern desktop resolution is a real gap.

The phone sizes are entirely absent. The two most important CSS pixel widths for phones in the 2020s are 375 and 390, corresponding to standard iPhones. The tool has 320x320, which is narrower than any modern phone in portrait orientation. A site that looks fine at 375 pixels wide might break at the smallest preset, because that width sits below the minimum that many responsive designs support. Testing at 320x320 will show you the worst case for very old phones, but it won't show you the experience of an iPhone SE or a Galaxy A series.

Tablets are also missing. The iPad in portrait is 768 CSS pixels wide. The tool has 800x600, which is close in width but has a different aspect ratio and a shorter height. A site that targets iPad portrait at 768x1024 won't be tested accurately by an 800x600 window. The height difference matters for sticky footers, modals, and viewport-height units.

The sizes that would make this tool more useful for modern web design appear in the table below.

This tool is best treated as a legacy desktop checker. For modern phone and tablet testing, you'll need to supplement it with browser developer tools or real devices.

Rate Limits and Privacy

This tool makes no request to the limitlessreferrals.info server when you run it. The form never submits. The JavaScript runs entirely in your browser, and the only network request that happens is the one your browser makes to load the URL you entered, in the popup window. That request goes directly from your browser to the target site. It doesn't pass through limitlessreferrals.info.

This has two practical consequences. First, there is no rate limit on the tool itself. You can run it a hundred times in a row and the server won't care, because the server never sees the test. Second, the target site sees your real IP address, your real user agent, and your real cookies. If you test a site that logs visitor information, it will log your visit as coming from your browser. This is the same as opening the site in a new tab yourself. The tool is transparent in that sense.

The only rate limit that applies is the site-wide throttle that protects every page on limitlessreferrals.info from abusive traffic. That throttle is about page loads, not about tool usage. If you load the tool page itself more than about fifteen times within a single second from the same IP address, the site may block that address for the rest of the day. Normal use, where you load the page once and run the tool many times, won't trigger this. The throttle exists to stop automated scraping, not to limit legitimate visitors.

There is no CAPTCHA on this tool. There is no user account required. There is no tracking of your test history. The tool is stateless. Each run is independent of every other run.

Browser Behavior Details

Because the tool relies on window.open(), the details of browser behavior matter. Chrome, Firefox, and Safari each handle popup windows slightly differently. Understanding these differences helps you interpret what you see.

Chrome, since version 64 or so, has ignored most of the window feature flags passed to window.open(). You can't hide the tab strip or the address bar in a popup window. Chrome does honor the width and height, but it clamps them to the screen size and applies a minimum size that's large enough to show the browser UI. A request for a 160x160 window will result in a window much larger than 160x160, because Chrome won't create a window that small. The viewport will be considerably larger than the requested size.

Firefox is similar. It honors width and height within limits but ignores many feature flags. Firefox also has a minimum window size. Safari on macOS is the most permissive of the three, but it still clamps to the screen and applies its own minimums. Safari on iOS doesn't support popup windows at all in the traditional sense, so the tool effectively doesn't work on iPhones and iPads. If you're testing on a mobile Safari browser, the popup will either be blocked or open as a new tab, ignoring the requested size.

The smaller presets, 160x160 and 320x320, will not produce a window that small on any modern desktop browser. You'll get a window that's larger than the preset, often much larger. The viewport width might be 500 pixels or more even when you selected the smallest preset. This makes the small presets nearly useless for their intended purpose. The larger presets, 1024x768 and 1366x768, are more reliable, because they're within the range that browsers will honor on most desktop screens.

Scrollbars also affect the measurement. When a page is taller than the viewport, a vertical scrollbar appears and takes up about 15 to 17 pixels of width, depending on the operating system. This reduces the available viewport width further. A site designed for exactly 1024 pixels of content width will see a horizontal scrollbar in a 1024x768 window, because the viewport is actually closer to 1009 pixels wide after the scrollbar and browser chrome are subtracted.

When to Use This Tool

This tool fits a narrow but real niche. Use it when you want to see your site in a real desktop browser window at a specific common width, with your real login session, without opening a new tab and manually resizing it. The tool saves you a few seconds of dragging the window edge. That convenience is modest, but for a quick check it's enough. Use it when you're testing a site that blocks iframes. Many sites send headers that prevent embedding, and if you've tried other online responsive testers that use iframes, you've probably seen blank boxes where the site should be. This tool doesn't have that problem. Because it opens a real window, any site that loads in a normal browser tab will load here.

Use it when you want to test a page behind a login. As long as you're logged into the target site in your browser, the popup window will share that session. This capability is useful for testing a dashboard or an admin page at different widths, something that most online tools can't do.

Don't use it as your primary responsive testing tool. For that, you need Chrome DevTools device mode, Firefox's responsive design mode, or real devices. The tool's fixed preset list, its lack of phone sizes, and its inability to emulate touch or pixel ratio make it insufficient for modern responsive design work. It's a quick check, not a comprehensive audit.

Related Tools

If you need a visual record of how a page looks, rather than a live interactive window, the Website Screenshot Generator captures an image of the page for you to save and compare.

If you're unsure what browser, operating system, or screen size you're currently using, the What is my Browser tool reports those details, which helps you interpret the results of a resolution test.

If your site loads slowly at certain window sizes because of heavy images or scripts, the Website Speed Checker measures load time and can point you to performance problems.

Frequently Asked Questions

Does this tool work on mobile phones?

No. The tool opens a popup window, and mobile browsers either block popups or open them as new tabs without honoring the requested size. Safari on iOS doesn't support popup windows in the traditional sense. Use this tool on a desktop or laptop browser.

Why did nothing happen when I clicked the button?

Your browser likely blocked the popup window. Look for a popup blocked icon in the address bar, click it, and allow popups for limitlessreferrals.info. Then click the button again. If you still see nothing, check that you entered a URL in the text field.

Does the tool test my site on a real phone?

It doesn't. A 320x320 window on a desktop is a small desktop window with a desktop user agent, no touch events, and no mobile pixel ratio. The tool resizes a browser window. It doesn't emulate a device.

Can I test a page that requires login?

Yes, if you're already logged into that site in your browser. The popup window shares your browser's cookies, so your session carries over. If you're not logged in, you'll see the login page and can log in within the popup window.

Why is the window not exactly the size I selected?

Browsers clamp popup windows to the physical screen size and apply minimum window dimensions. The width and height you select set the outer window size, so the viewport is smaller after subtracting browser chrome and scrollbars. A 1600x1200 request on a 1366x768 screen will open a window that fits the screen.

What are the eight preset sizes?

The presets are 160x160, 320x320, 640x480, 800x600, 1024x768, 1366x768, 1152x864, and 1600x1200. The default is 1024x768. There is no custom size input and no phone or tablet preset.