Safari for iPhone ignores viewport settings on .mobi domains 

Tags :
iPhone Simulator

While working on the redesign of a client's website, I ran into a weird issue with Safari for iPhone: whatever device-width I specified in the viewport meta tag, the web site would render at 100%.

The viewport

For Safari on iPhone OS, the viewport is the area that determines how content is laid out and where text wraps on the webpage. The viewport can be larger or smaller than the visible area.

Safari on iPhone OS sets the size and scale of the viewport to reasonable defaults that work well for most webpages. The default width is 980 pixels.

For example, to set the viewport width to the width of the device, add this to your HTML file:

<meta name="viewport" content="width=device-width" />

If the webpage is narrower than the default width, set the viewport width to the width of your webpage accordingly:

<meta name="viewport" content="width=800" />

According to Apple's documentation «[..] the goal of Safari on iPhone OS is to fit the webpage in the visible area when completely zoomed out by maintaining a ratio equivalent to the ratio of the visible area in either orientation». So most, if not all, web sites are rendered correctly in Safari on the iPhone.

Except the one I was redesigning :/

After spending a lot of time debugging my markup and CSS, I gave up, and postponed this issue to later, concentrating of the website redesign itself. Launch time approaching, this issue stuck out more and more on my todo list, until half an hour ago.


Well it turns out it has all to do with the domain's name TLD: .mobi (dotMobi). I chose this domain to develop the website on while the current one was running on its .com TLD. The switch would be easy enough come launch time.

I have never taken much time to look into dotMobi since it launch in 2006, but according to its Wikipedia entry «dotMobi does not itself mandate any particular technology, but does require that .mobi sites produce user experiences consistent with their guidelines and specifically optimized for mobile phones». I would never have imagined that a browser would treat a website differently based solely on its TLD.

The only other available browser on the iPhone (Opera Mini) renders it as a normal web site. It's only when I thought to load the web site using its IP number instead of its domain name that I understood what was going on.

I suppose this makes sense from a default behaviour point of vue: the site is supposed to be optimised for mobile viewing, but I don't understand why the viewport settings aren't taken into account if they are present.

Feeling relieved, I needed to share this info with you.

Posted a response ? — Webmention it

This site uses webmentions. If you've posted a response and need to manually notify me, you can enter the URL of your response below.

Comments and responses

  • 29 Apr 2010

    Wow, that’s really weird, but incredibly handy to know – especially like you say – not being an obvious thing to debug or understand. I wonder what made them implement it like that?

  • 05 May 2010

    I have to admit that on first reading this I thought there was no way that it could be true.
    So we tried testing it here at dotMobi and can confirm that your experience is repeatable—we tried the same page with a .mobi address, a .com address and a local intranet address (no top level domain suffix) on a 3GS.
    That said, the effect doesn’t appear to have anything to do with the viewport tag—we experienced the same effect without it. It’s difficult to guess what Apple is at here, and why they choose to render the page slightly differently based on the TLD. On the plus side it does suggest that they are trying to optimize the rendering of the page if they believe it’s mobile-friendly, which sounds like a good thing.
    Interesting sleuthing, thanks for sharing.
    Ronan Cremin, dotMobi

  • 05 May 2010

    @Ronan Cremin: thanks for confirming this.
    The reason why I mentionned the viewport meta tag, is that whatever the settings were (size, scaling, etc.) Safari for iPhone had its own rendering interpretation when the page was requested from the .mobi TLD. The rendering was different when requested from the .com TLD (or the IP address) – namely, the viewport settings were honored.
    Thanks again for your comments.

  • 18 Nov 2010

    I’m glad I found this post, I thought I was going mad!
    While I understand the reasoning behind why Apple might do this, changing behaviour purely based on the domain is madness.
    You should at least be able to override it. I’d suggest the presence of a meta viewport should tell Safari “hey, I know what I am doing, let me be”. If the meta viewport is missing sure then lock it down to 100% or whatever its actually doing.

  • 18 Nov 2010

    @Chris Blown: you are right. Thanks for your comment.
    As of today, I still haven’t found any documentation explaining this behaviour.

  • 22 Mar 2011


    Interesting. Had to discover it the hard way today.

  • 22 Mar 2011

    @mrfusion: sorry to hear that. Thanks for your comment.

  • Hi David,
    thanks for your article – I discovered that issue today, too.
    I’ll let my domain redirect to this article until it’s closed…

  • 01 Jun 2012

    This is madness!

  • 25 Jul 2012

    Incredible but true.
    We spent a lot of time on one project trying to figure out why a copy of SlideDeck wouldn’t render properly. Just moving it to a non-MOBI domain resolved everything.
    These days as web developers – it’s taking longer for us to test and perfect our projects.

  • 25 Sep 2012

    Google Chrome on iOS (iPhone) shows the same behaviour. As Mobile Safari and Google Chrome both use Webkit as their rendering engine the problem seemes to be caused by Webkit.
    Still can’t believe it …

  • 25 Sep 2012

    filed a bug here

  • 25 Sep 2012

    Thanks @Philipp :)

  • 27 Sep 2012


    @Philipp Metzler Are you sure that it is really in the base WebKit?
    I understand that Chrome on iOS is really just Safari since Apple doesn’t allow other browser engines on iOS. So the issue could just be Safari alone.

  • 30 Sep 2012

    See the detailed bug review in

  • 06 Oct 2012

    Thanks @Binyamin :)

Want more ? — prev/next entries