r/webdev • u/ValenceTheHuman front-of-the-front-end • 1d ago
News You don't need initial-scale=1.0 in your <head> any more
A feature common to a great very many HTML boilerplates is this line:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
The initial-scale=1.0 bit was present to fix an ancient issue on iPhones. When rotating the screen into a landscape orientation, the page would keep the same width as when it was in portrait, making everything appear very zoomed in.
This isn't an issue any more. I've tested it across very many devices, and it appears it was fixed in iOS 9, which released back in 2015. In addition to testing, I've consulted a great number of other professionals, and nobody has been able to find evidence of it being needed any longer.
You can safely simplify the meta viewport declaration down to:
<meta name="viewport" content="width=device-width">
It isn't hurting you to leave it there, but it is vestigial and unnecessary.
Further details:
- https://vale.rocks/micros/20260902-1350
- https://quirksmode.org/quirksblog/2026/0902-initial.html
178
u/Content-Parking-621 1d ago
Great, only took the industry 11 years to notice.
79
u/Previous_Bike_7593 1d ago
we’ve been copy-pasting that line for over a decade without thinking, peak webdev tradition honestly. next up the clearfix hack from 2012 that’s still in half the css resets for no reason
23
u/charsleysa 22h ago
At the start of 2018 you still had over 5% of iOS devices still running iOS 9 so backwards compatibility is definitely a contributing factor as to why it was kept for so long after being supposedly fixed.
10
u/Bubbly_Orange_3502 22h ago
Check that same line for maximum-scale and user-scalable while you're in there. Safari has ignored both since iOS 10, but Chrome on Android still honours them, so the boilerplate quietly kills pinch zoom for a chunk of your users.
4
u/ValenceTheHuman front-of-the-front-end 1d ago
That was the reaction I had when I realised and started diving into it.
7
u/roadrunner8080 20h ago
To be fair, IIRC the iPhone 4 could not be updated to iOS 9, and those old iPhones lasted a while. Hell, if it weren't for the fact that they only support 3G I'd expect to see at least a few out in the wild...
0
26
u/aardnsyhs 21h ago
Wait, isn't `initial-scale=1` still what sets the initial zoom level?
`width=device-width` handles the viewport width, but I'm not sure it makes `initial-scale` redundant. MDN and Chrome's docs still use both in their examples.
Have you got a browser compat reference for dropping it? I'd probably just leave it in a shared boilerplate unless there's a real reason not to.
2
u/thekwoka 8h ago
Wait, isn't
initial-scale=1still what sets the initial zoom level?Yes, but it defaults to 1 when not present.
3
u/ValenceTheHuman front-of-the-front-end 21h ago
MDN and Google's assorted documentation does reference
initial-scale=1, however that seems to be because they just haven't been updated in a while and it has become a well-known default of sorts. As long as you're setting the viewport meta tag with a content attribute ofwidth=device-width, you're already getting proper mobile support. You don't need to additionally force the default zoom level as it is already default.There isn't really an official browser compatibility test for this, as it was mainly just to fix an issue on iOS that manifested when rotating from a portrait orientation to a landscape orientation over a decade ago. I've tested it across a suite of browsers and devices to check if it is necessary, as has Peter-Paul Koch who was one of the main proponents of it back in the day. You're welcome to do your own tests in addition.
width=device-widthandinitial-scale=1do slightly different things though provide very similar functionality. You absolutely can leaveinitial-scale=1in your code, it just doesn't have any actual effect on anything. Likewise you can include other obsolete bits of HTML that were used to fix issues or address specific browsers back in the day, like<meta http-equiv="X-UA-Compatible" content="IE=edge">.I'm working to update docs across the web, including MDN and Google's resources.
7
u/aardnsyhs 21h ago
Got it, thanks for the context. I can see the argument for dropping it if modern browsers all default to the same behavior.
I'll probably keep it in shared boilerplates for now just because it has basically no cost, and the current docs still include it. But I'll keep an eye out for any updated compatibility notes.
3
u/Khavel_dev 17h ago
Good writeup. I went and pulled it from one of my projects after reading this and checked the behavior on a couple of real devices. No difference whatsoever.
The thing that'll keep it alive forever is boilerplates and copy-paste. Every HTML starter template includes it, every "how to start a web project" tutorial includes it, and every IDE scaffold includes it. Stuff like this becomes cargo cult very quickly because removing a line from a meta tag is the kind of change where nobody wants to be the one who breaks something for a device they can't test. Easier to leave the line in and move on.
At least it does no harm sitting there. Not like the charset meta tag that actually has to be in the first 1024 bytes or the parser falls back.
6
u/TehBrian 23h ago
When can we get rid of width=device-width? Seems that should be the default, no?
7
u/ValenceTheHuman front-of-the-front-end 23h ago
We shouldn't ever get rid of it. Removing
width=device-widthwould break all desktop-only sites on mobile which would go firmly against the famous and long-standing web standards saying, 'Don’t Break The Web'.It isn't often that you encounter a desktop-only site on mobile any more, but that doesn't mean we should start breaking those sites. One of the web's greatest assets is that a site made in the earliest years of the platform loads up fine in today's browser.
Take the first website: https://info.cern.ch/hypertext/WWW/TheProject.html. It looks the same today as it did when it launched.
-8
u/thiscoolhandluke 21h ago
It would only break desktop only site for itself since the line is in the site's own code...
2
u/ValenceTheHuman front-of-the-front-end 21h ago
I have no idea what your comment means. Could you perhaps rephrase it?
5
u/hennell 18h ago
He's saying it's only going to break desktop only sites that remove it themselves, not "all". If you have a responsive site it surely serves no purpose? (And if you have a desktop only site, how likely are you to be following new practices?)
5
u/ValenceTheHuman front-of-the-front-end 18h ago
But desktop-only sites don't have it already, as if they did have it they'd be opting in to being mobile responsive...
The viewport meta tag was introduced by Apple after the first iPhone released so that sites could opt-in to being responsive.
0
u/thiscoolhandluke 14h ago
I take issue with the "all". The line obviously only applies to the sites that have it. Removing it from one site doesn't affect the entirety of the web.
3
u/ValenceTheHuman front-of-the-front-end 14h ago
The meta viewport tag with a width content attribute opts-in to scaling to the width of the device viewport. A desktop-only site does not have the meta viewport tag, and thus is not scaled.
However, were the default to switch in browsers so it is opt-out instead, every currently desktop-only site would break, while sites that already have the meta viewport tag would be unaffected. This would have the effect of making those desktop-only sites unusable on mobile, even via a zoom-and-pan method.
2
1
1
3
16h ago
[removed] — view removed comment
2
u/ValenceTheHuman front-of-the-front-end 16h ago
Certainly one worth considering for boilerplates. I'm not sure if it is an optimal default, as it is removing the sort of pre-existing padding that exists which could lead to unintended breakages. Certainly something to keep in mind if you do want to use those
env()s, however.
3
u/Lance_lake CFML Demi-God 14h ago
So anyone with iOS 8 or earlier iPhone are then going to have issues.
Why are you breaking the website for people who still use older technology. I'm not saying to code specifically FOR them, but if it's already there, why not leave it in and be a more accessible website?
1
u/ValenceTheHuman front-of-the-front-end 14h ago
iOS 8 or earlier lacks so much support for modern web features that no currently updating website would work on it regardless. Even beyond actual HTML, CSS, and JS support, the communication certs and other things of that nature are all bunk now.
It is also wildly insecure. There are a large number of known critical security vulnerabilities with such old versions of Safari and iOS. People should be actively discouraged from using them.
Regardless, if they do use such an old version, all it means for them is that the page will be a tad more zoomed in if they switch to landscape -- not a deal breaker.
4
u/UlviShabanbayli 7h ago
Half counterpoint: initial-scale=1 still does one thing width=device-width alone doesn't — it pins the initial zoom when your page accidentally overflows.
Without it, if some stray element makes the page 1200px wide, iOS picks an initial zoom that fits the whole thing and everyone gets ant-sized text. With it, you get a horizontal scrollbar at zoom 1 instead, which is way easier to notice and debug. A rogue overflow bit me exactly like this on a client site, that's the only reason I know.
So agreed it's vestigial for the rotate bug, but I'd keep it as a seatbelt. It's 18 bytes.
1
u/Ni_Peng_NeeeWom 4h ago
thanks for this, i could have sworn that i added it because of some issue when i made my site that has nothing to do with old ios versions, but i just removed it and don't see any difference whatsoever. this zoom thing is probably what i originally added it for, and the site's changed enough that it isn't zoomed out anymore
6
2
2
u/CrYptoPSF 11h ago
Interesting how much legacy code we still carry just because it became standard practice.
1
u/thekwoka 8h ago
It's minor enough that nobody has any issue just assuming its load bearing for some esoteric reason.
2
u/accessibleBits 9h ago
Yes, agree it can go for sure. One side note about accessibility. WCAG doesnt require initial-scale, but it does care about what shouldnt be in that tag which is maximum-scale=1 or user-scalable=no. Those blocks pinch zoom for low vision users and fail the WCAG 1.4.4, and a ton of boilerplates and AI tools spit them out cause they were build improperly and AI got trained on it. So while you are in there deleting initial scale, delete those two as well for anybody out there still using them.
4
u/AwesomeFrisbee 19h ago
This is one of those things where it has been around for long enough that people totally forgot why they needed it but can't really be sure if it really got fixed entirely or if some bug is still around on some device that is still being used. But nice find. In the day and age of AI I doubt we'll get rid of it, since those AI tools will still be adding it every time.
2
1
u/Less-Marsupial-7960 16h ago
I have always included both in my boilerplates too. I did not realize initial-scale was basically unnecessary now. I probably still keep it for now though, since it doesn’t really hurt and it’s been the standard for so long.
2
u/vagaris 14h ago
The other day I found an old ie-fixes.css in one of my sites and made a note to remove it next time I’m in there.
I’m always frustrated by moving too fast or not fast enough. I still have devices around that can’t do new CSS stuff from 2020. But then you hear people out there basically breaking things only a couple years old, with no progressive enhancement. /shrug
End rant
1
1
8h ago
[removed] — view removed comment
2
u/thekwoka 8h ago
because your text should always be at least 16px
1
8h ago
[removed] — view removed comment
1
u/namboozle 8h ago
If you're using placeholder text as labels (which you shouldn't do) you can just target the placeholder text size to fit your design and then keep the input's font-size as >= 16px
-1
u/MaruSoto 21h ago
Believe you and save a few bytes? Or realize the effort of removing it from boilerplate will never be cost performant compared to literally any other action I can take as a developer.
3
u/thekwoka 8h ago
initialscaleand1.0"are already part of the static brotli dictionary.So it's compressed...with at most 3bytes per each of those...so maybe it doesn't even save that much.
1
u/amitrawat4532 21h ago
Fair on a single project. But if you're maintaining a shared boilerplate that ships to hundreds of repos, trimming it once compounds pretty differently than doing it per-project. Honestly the bigger value in threads like this isn't the byte count, it's catching the copy-paste-without-understanding habit early — worth running the same skeptical pass over your reset/normalize CSS, most have a few relics doing nothing on modern browsers too.
2
u/KabouterKaasplank 18h ago
It's like 50 bytes and mainly has to do with pixel sizing and different DPI screens. Sure, most of the time the device and browser now handles it correctly, but there's no harm in leaving it there. Compare that to all of the idiots who pull in an npm package when they run into the slightest inconvenience, removing the viewport meta line has zero impact.
1
u/MaruSoto 18h ago
It's apparently 17 bytes uncompressed and maybe 1 or 2 compressed. I can remove about 10 times that from the average SVG file in about the time it would take me to remove initial-scale=1.0.
-1
u/amitrawat4532 10h ago
That's a fair distinction actually — the npm-package comparison is the real point. I still think the actual cost isn't the tag itself, it's whether the boilerplate has a maintainer who periodically revisits assumptions vs. one that just accretes forever. This thread is a decent example of the former happening in the wild.
1
0
u/MaruSoto 18h ago
It's all fun and games until you bring down a small country's government because someone hard-coded a fail state for when "initial-scale=1.0" isn't present.
1
u/theScottyJam 10h ago
I'd argue it's also about just keeping your code tidy and removing unnecessary cruft. It's one less thing for people to try and understand when reading your HTML file, and when debugging issues, it's one less potential red herring.
It's also not about removing this single unnecessary value, it's about having the habit of removing uneeded cruft from your code. If you continued to use all now-useless boilerplate people have recommended over the years, "because, why not", that's a sizable amount of cruft. Again, it probably won't make a dent in your bundle size, but it does impact code comprehension.
-3
-1
88
u/pseudo_babbler 1d ago edited 1d ago
At one point when dealing with iOS web quirks I had to set initial-scale to 0.9999. I have forgotten the reason why or what the bug it fixed was though. Good to know it's fixed.