Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Meet XRespond Testing Tool: Let’s Make Building Responsive Websites Simpler

The way people consume information is constantly evolving. As web designers and developers, we keep up with all of the different screen shapes and sizes, learning to create beautiful, flexible software. Yet most of the available tools still don’t reflect the nature and diversity of the platform we’re building for: the browser.

When I was making my first responsive website in 2012, I quickly realized how inefficient and time-consuming the constant browser window resizing was. I had just moved from Estonia to Australia, and with a newborn, time was very much a precious resource.

I began looking for better ways to see the effects of my media queries.

I came across Matt Kersley’s Responsive Web Design Testing Tool1 and was blown away. It cut my development time in half. Even though the app was quite basic, it quickly became indispensable, and I continued to use it for several years.

Matt Kersley’s Responsive Web Design Testing Tool2
Matt Kersley’s Responsive Web Design Testing Tool. (View large version3)

It was very much to my surprise that I never saw this brilliant concept taken any further. This, combined with the lack of features, set me on a journey to create the open-source virtual device lab XRespond74.

The new Smashing Magazine website previewed in XRespond5
The new Smashing Magazine website previewed in XRespond (View large version6)

Understanding The Problem Link

When it comes to developing responsive websites, the problem lies in having to constantly resize the browser window. Although this unavoidable action feels second nature to most, it also masks aspects of design we don’t often appreciate — most notably, inconsistency and time management.

With designs usually appearing in some combination of mobile, tablet and desktop context, anything in between is left in a somewhat uncertain state. And filling these gaps requires a lot of time and effort.

The problem lies in the difficulty of looking at one screen size at a time, as opposed to getting an all-in-one overview of different screen sizes. When we’re building for a variety of screen types, it doesn’t make sense to view only a single instance of a design at any given time — we’d be unable to gain the context of how the styles of elements change across breakpoints.

Current practices just don’t cater to these modern ways of developing. Fortunately, it’s not all bad news.

Simple Solution Link

XRespond74 is a virtual device lab for designing, developing and testing responsive websites. The idea is simple: It enables you to make website comparisons side by side, as if you had different devices on the wall in front of you.

You don’t have to leave your desk, laptop or even favorite browser. And with zero setup, you can start comparing websites right away.

(View large version9)

XRespond can help if you’re building a pattern library or a style guide, because you can focus on a single component at different screen sizes simultaneously. As you’d expect from a development tool, it works well with local servers.

Just bear in mind that, as with any emulation, XRespond can’t compete with testing on real devices, but it will get you 90% of the way there — and in a fraction of the time.

How To Use It? Link

Enter a website address, click the button, and XRespond will automatically display the website on different virtual devices — which you can choose and customize as you see fit.

XRespond works well with other development tools, notably one of my favorites: Browsersync10. Browsersync enables you to set up live reloads and synchronized scrolling — all simultaneously across virtual (and real) devices. This makes spotting problems simpler, because issues become more apparent.

Synchronized scrolling across devices with Browsersync11
Synchronized scrolling across devices with Browsersync (View large version12)

What To Do If Your Website Won’t Load? Link

Occasionally, you might run into a problem of your website failing to load. This most likely has to do with your website preventing itself from being loaded in an iframe. If you own the website, you can temporarily disable X-Frame-Options13 or the Content Security Policy14, depending on your setup.

Conclusion Link

I love XRespond — and not just because I love making it, but because it simplifies my life. I can spend less time and effort working, and use the spare time for something else. It’s given me an opportunity to improve the quality of my work. I hope you’ll find XRespond just as useful and will start enjoying the time it saves you.

Feel free to share, and follow me15 on Twitter for updates. Cheers!

(da, il, al)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15

↑ Back to top Tweet itShare on Facebook

Indrek is an ex-graphic designer, who half-way through his career turned to code and hasn’t looked back since. The past eight years have shaped his passion for responsive web design, accessibility, and performance. If it’s not the Web, it’s his love for exploring music and playing records.

  1. 1

    Hi, nice work! It looks really nice.
    I would like to ask you if is possible to have a feature where I could see every opened windows at once, like zoom out the whole viewport but without using browser’s zoom because it distorts how things really look like in every simulated device.
    Something like this
    Instead of this

    Thank you!

  2. 4

    240px? really? -.-

  3. 5

    I find that today it’s not about making web to fixed screen sizes. Rather taking wider perspective. Define rules that address certain size ranges. There are way more screen sizes and aspect ratios than one has time to focus on.
    But nevertheless, it sure helps, but won’t go as bold as stating “cut my development time in half”

    • 6

      Hi Ardo. I understand your concern and I can assure XRespond doesn’t promote developing for fixed screen sizes. Responsive design is (by definition) fluid, and should be regardless of preview tools. Technical limitations aside—XRespond is no different than using real devices during development. Cheers!

  4. 7

    This is amazing! Having to go into developer tools just to switch between different views or resizing the screen on the browser takes more time and makes it hard for comparison. I love the layout and display of XRespond as well, it’s very clean and makes the content stand out on the page so well. I will most definitely be using this for all future projects.

  5. 8


    September 7, 2017 3:28 pm

    There is also a chrome extension named “Emmet Re:view”, which does the same task and I think it’s better than Xrespond as we have not to visit another URL for checking our site. :)
    Also we can test the sites on local server, which make it stand above all :P .
    Get it here –

    • 9

      Hi TechiePriyaRanjan, Emmet Re:view is an awesome tool, but unfortunately limited to Chrome only. Since it’s also an extension, it has some nice additional features compared to web apps alike. XRespond chose to be a (browser-agnostic) web app, so anyone could use it. Cheers!

  6. 10

    It’s like if you came with your tool from heaven, just when I was ready to start working on the ‘responsive’ part of a website.

    Just two things I think it lacks, if you ever reach to comments and maybe you agree with:

    1. It would be great if you could give an URL as a parameter, so you don’t have to put the URL on the input box. That could let someone even do a bookmarklet or something. I mean, something like “”

    2. A button to refresh/reload each device view. At first I thought those were reload buttons, not rotate buttons… I use to work old fashion, so to see changes in one particular view I have to refresh the whole page.

    • 11

      Agustin D'Atri

      September 7, 2017 7:49 pm

      If you are in a development environment and the framework you are using has livereload configured, you can simply fill the XRespond URL input with your local URL like “http://localhost:4200/” and when you make a change in the app, the iFrames in XRespond will refresh automatically.


    • 13

      Thanks for your suggestions. The URL parameters is indeed a useful feature I’m planning to implement. As for refreshing the entire page, you could hit the “Load URL” button instead, which will reload the devices, but not the page.

      Feel free to help with improvements. The code is available on GitHub and I’m more than happy to accept a PR. Cheers!

  7. 14

    The iframe issue is a show-stopper for me. Changing my code back & forth is more time consuming than using built-in browser testing, such as chrome device toolbar.

    Simply resizing the window of a browser is pretty much the quickest way to do very basic tests – test when breakpoints kick-in. Fine tuning for key breakpoints using in-browser test tools is the second test and finally, actual device testing, which always throws up unexpected issues not noticeable in the basic resolution tests.

    I guess it depends on your dev setup, dual monitors at 1920px wide allows for quick mobile, tablet, desktop testing in multiple browser windows, along with your editor window (just about). Couple that with live reload & as a quick test workflow method, it can’t be beaten.

  8. 15

    To make it easier to see the examples in the iframes you should use translate to reduce the visual size of them while still keeping the right viewport dimensions (it’s what I did on

  9. 16

    XRespond is nice but I prefer the Chrome extension “Emmet Review” because it scales devices with appropriate dpi zoom simulation and scales the pages to fit on one monitor. It also scrolls all of the devices at the same time.

  10. 17

    This looks great, the new smashing site not so much. I don’t think I can handle that much red, even the preview makes me a bit uneasy.

  11. 18

    Great tool! You should add an option to extend the width of the iframes by the scrollbar width of the OS. (Because it can be misleading when a ~16px scrollbar appears in the test frame.)

    • 19

      Hi Dan, thanks for your suggestion. What you’re describing is a common inconsistency—some browsers/platforms include the scrollbars in viewport dimensions while others don’t. This has a direct effect on how the media queries are being applied. XRespond allows you to use custom viewport dimensions, so you can find the approach that works best for you. Cheers!

  12. 20

    The problem lies in the difficulty of looking at one screen size at a time, as opposed to getting an all-in-one overview of different screen sizes. When we’re building for a variety of screen types, it doesn’t make sense to view only a single instance of a design at any given time — we’d be unable to gain the context of how the styles of elements change across breakpoints.

    This paragraph that doesn’t make much sense to me. I focus on one screen at a time and I have no problems, even with complex designs. Switching screen sizes isn’t hugely frequent as I complete the site linearly, widget by widget, screen size by screen size.

    I already have a good idea of what my code will produce in other screen sizes, because I’ve planned and chosen a specific approach for the situation. I need to take the design for all screen sizes into account before I do the code, so I can choose the best approach, instead of making it up as I go. In any event, I finish coding for the current screen size and move on to the next. The only time I’ve run into issues is when I don’t plan my approach to the code.

    I don’t understand the problem that this advertisement is trying to solve. Can you provide any real case scenarios where this tool has helped you to avoid an issue that you would have run into without it? I would really like to understand why coding for one screen size at a time can be difficult and what issues you run into.

    • 21

      Hi Karl, thanks for an excellent comment! From what you’ve described I can see we have a very similar take on coding and planning. Presumably, this approach is a result of experience and very different from the one I used to build my first responsive websites with.

      Using XRespond has led me to write less code even quicker, since I can see—at once—which styles are in effect down the media queries. This level of overview and immediate feedback allows me to make even better and fine-grained decisions which are too detailed for planning. Cheers!

  13. 22

    A simple Javascript snippet I wrote which can be dropped anywhere between the body tags and works on all desktop browsers, not just Chrome- = 'scroll';
    var mySizeDisplayer = document.createElement('div');
    sizeFinder(); '1000'; = 'fixed'; = '0'; = '0'; = 'sans-serif'; = '8pt'; = '#ff9999'; = '0 2px';
    window.addEventListener("resize", sizeFinder);

    function sizeFinder() {
    var theScreenWidth = document.documentElement.clientWidth;
    var theScreenWidthText = 'screen width: ' + theScreenWidth + 'px';
    mySizeDisplayer.innerHTML = theScreenWidthText;

  14. 23

    Hi Indrek Paas,
    I liked your idea but I am having problem rendering my site ( It’s not rendering same as in mobile/google dev. Some sites looks fine some are not.

  15. 24

    When I type the URL and click load the page loads in three modes but then in a second I get moved to the real website. Does anybody have the same problem? :/ (Chrome 61)

    • 25

      Hi Sebastian, I think what you are describing is called frame busting, where the parent of an iframe (XRespond app) is forced to navigate with JavaScript. This can be fixed in two ways: either in your script or in the app with a sandboxattribute on the iframes. If you feel like helping out with this fix, the code is available at GitHub and I’m more than happy to accept a PR. Cheers!

  16. 26


    Bookmarked! Will definitely be using this.

    One suggestion – you should add in the ability to collapse the header and div.toolbar elements to make it more usable on screens with a bit less height :)


    • 27

      Hi James, great suggestion to maximise screen real estate on smaller screens. I’ve added it to the backlog, but if you’d like to help out with this feature, the code is available at GitHub and I’m more than happy to accept a PR. Cheers!

  17. 28

    It’d be great to have the various simulated viewports kept in sync by default. I.e. when a link is clicked, they _all_ respond to that click. Perhaps scroll, too.
    Thanks to the other commenters for mentioning Emmet Review, looking at that now.

  18. 30

    Hey nice tool but, as you said it, responsiveness is not only about resolution.
    Mobile devices have touch related problem, pixel density, zoom, dynamic viewport size (top bar disapearing), in-between resolutions, etc. And unless if you test on real devices, you often discover issues afterwards.

  19. 31

    John Flickinger

    September 12, 2017 6:29 pm

    Please forgive me if I missed this in the article, but is this just simulating the screen sizes for each device, or simulating the device itself? For example, if I’m using XRespond in Chrome to view an iPhone 7 am I looking at the way Chrome renders the page at iPhone 7’s screen size, or is mobile Safari being simulated the way it is in the iOS Simulator in Xcode?

    Either way it’s a very helpful tool and should save at least some time in development, and I’m looking forward to using it.

    • 32

      Hi John, XRespond simulates device screen sizes. The browser you’re using XRespond with is also rendering your website in iframes. XRespond’s intention is to streamline certain stages of responsive web development—specifically around media queries. Cheers!

  20. 33

    Demetrius Sullivan

    September 14, 2017 7:34 am

    Hi Indrek,
    Nice Blog! This explains exactly what I was looking for in website design. Thanks Buddy!

  21. 34

    Hello may I ask you how is your tool different from Which does the same?

    • 35

      Hi Tom, XRespond and Sizzy are both based on the same concept by Matt Kersley, but differ noticeably by implementation and features. If you’re question is more about “why have one tool when we have another one already?”, then XRespond was released about a year before Sizzy.

      Hope that helps, cheers!

  22. 36

    Similar tool but can load any website


Leave a Comment

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top