5 Things You Didn’t Know About the Viewport Meta Element
by @frontenddogma@mas.to on , tagged html, metadata, viewport, mobile, zooming, accessibility, performance (share this post, e.g., on Mastodon or on Bluesky)
Few lines of HTML have been copied as often as this one:
<meta name="viewport" content="width=device-width, initial-scale=1">Apple introduced the viewport meta element with the first iPhone in 2007, and it has been part of almost every responsive website since. (Declan Chidlow’s Antiquated HTML Snippets and Artefacts reminds us of what came before: HandheldFriendly for AvantGo and BlackBerry, MobileOptimized for Windows Mobile.) Yet the material featured on Frontend Dogma over the last few weeks shows that the element is anything but settled—it’s getting shorter, it’s getting new options, and it’s getting a sibling.
Here are five things you may not know about the viewport meta element.
1. You No Longer Need initial-scale=1
In August, Manuel Matuzović wrote in My HTML Boilerplate in 2026 that initial-scale=1 “shouldn’t be necessary anymore”—with the caveat that “if you want to play it safe, it doesn’t hurt to add it.”
On September 2, Declan settled the question. After asking on the fediverse whether the value was still needed, they found that the iPhone now switches layout viewports correctly with width=device-width alone, and concluded in You Don’t Need “initial-scale” in Your HTML that all you need is this:
<meta name="viewport" content="width=device-width">The same day, Peter-Paul Koch picked up on Declan’s finding and marked “initial-scale” No Longer Needed as “the end of an era.” Peter-Paul’s post also explains why the value had been needed: The original iPhone did not change the layout viewport on orientation change with width=device-width, while initial-scale=1 did. Other browsers copied that behavior, and so both values became necessary for “perfect compatibility.”
Declan has since made the change in My HTML Boilerplate, too.
2. It’s a Performance Feature
The viewport meta element doesn’t only affect layout. Browsers used to wait about 300 milliseconds after each tap to see whether a second tap—a double-tap to zoom—would follow. Chrome removed that delay in 2014, but only for pages with a mobile-optimized viewport.
DebugBear’s How to Optimize Viewport for Mobile for Faster Interactions shows what happens when that’s not the case: An airline website whose HTML contained a proper viewport element overwrote it with width=480 via JavaScript on small screens. Every tap got delayed, and Interaction to Next Paint (INP) suffered so much that only 1% of users had good Core Web Vitals. Lighthouse now checks for this dynamically, which is why a correct element in your HTML source isn’t necessarily enough.
3. It Can Decide What the Virtual Keyboard Does
When the virtual keyboard opens on a phone, what should resize—the visual viewport, the layout viewport, or neither? Since Chrome 108 (2022), you can tell the browser with the interactive-widget key:
<meta name="viewport" content="width=device-width, interactive-widget=resizes-content">Bramus Van Damme explained the three values—resizes-visual (the default), resizes-content, and overlays-content—in Control the Viewport Resize Behavior on Mobile With “interactive-widget”. The news this fall is that it’s no longer just a Chrome and Firefox (for Android) feature: As Bramus reports in WebKit Supports “interactive-widget”… and Hopefully Safari Will Too?, WebKit implemented it in August. It hasn’t shipped in Safari yet—but if you ever had a virtual keyboard cover a fixed toolbar, it’s something to watch.
4. Turning Off Zoom Is Never the Fix
maximum-scale and user-scalable are still common in viewport elements, and they’re still harmful. Declan says they “greatly harm accessibility and should never be used”; preventing zoom also violates WCAG.
What makes this worth repeating is that there’s usually a better solution for the problem people try to solve with them. In Stop Buttons Triggering Zoom When They’re Double Tapped, Andy Bell describes a radio player whose page zoomed in and out as users quickly tapped through stations on iOS—despite a correct viewport element. The fix is a single line of CSS, not a change to the viewport:
.button {
touch-action: manipulation;
}That disables double-tap zoom on those elements while keeping pinch zoom available.
5. It’s Getting a Sibling: text-scale
About a third of phone users have changed their system text size, but mobile Safari and Chrome ignore that setting on websites. Josh Tumath proposed a fix to the CSS Working Group in 2024; Try Text Scaling Support in Chrome Canary introduces the result—now part of CSS Fonts Level 5:
<meta name="text-scale" content="scale">The idea mirrors the viewport meta element: Just as width=device-width tells browsers that a site is built for small screens, text-scale tells browsers that a site still works when users increase their text size. It’s opt-in for a reason—most sites would break otherwise.
Manuel tested it in A New Meta Tag for Respecting Text Scaling on Mobile and found that only text set in relative units scales, and that adding the element caused horizontal scrolling on matuzo.at. Josh’s advice: Don’t override the root font size (like :root { font-size: 16px; }), use font-relative units for content, and test at 320 pixels with 200% text size. Both Manuel and Declan already include text-scale in their boilerplates.
What to Take From the Viewport Meta Element
An element most of us stopped thinking about years ago has been quietly changing. Your boilerplate can drop initial-scale=1, your viewport element should never block zoom, and overwriting it with JavaScript can cost you performance. New options let you control the virtual keyboard and, soon, respect your users’ text size settings.
The common thread: The viewport meta element is how we tell the browser what our site can handle. Make sure it says the right things.
For more, see Frontend Dogma’s viewport, zooming, and metadata coverage.
(Parts of this article were edited with the help of AI.)