Website Dimensions

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Every dimension that matters when you design, build or brief a website — real screen resolutions, container widths, framework breakpoints, image sizes for every placement, social and share-card specs, favicon sets, and the two attributes that stop your layout jumping. With the reasoning behind each number, so you know when to break it.

The short answer

Dimensions are the part of web design people most want a single table for, and the part where a single table is most misleading. The right number depends on where the asset renders, how wide its container gets, and what pixel density you are serving. This guide gives the numbers and the reasoning, because the numbers change and the reasoning does not.

Website dimensions in one paragraph

Answer first: the standard web width most teams settle on is a 1200 to 1440 pixel content container inside a full-width page, and the mobile website size worth designing against is 360 CSS pixels wide. Those two figures — the standard web width for desktop and the mobile web page size at the narrow end — cover the overwhelming majority of real sessions. Everything else on this page is either a refinement of them or an asset-specific website screen dimensions question.

Webpage size, page weight and page resolution are three different questions

People searching webpage size mean one of three things and the answers are unrelated. Layout size is the width and height in CSS pixels, covered in the width and viewport sections below. Page weight is how many kilobytes the page downloads, covered in the weight budget section. Website page resolution is about pixel density and 2x assets, covered under image dimensions. Decide which one you actually need before taking a number from this page. A single size for website work does not exist, and anyone offering one is answering only one of the three.

How to use this page

If you need one figure quickly, the tables are self-contained — take the number and go. If you are setting a standard for a team or writing a brief for a developer, read the reasoning under each table, because that is what stops the standard being wrong in six months.

The one rule underneath all of it

Design to the container, not to the screen. A 1920px monitor showing a 1200px content column with a two-column split inside it means your image box is about 580px wide, not 1920. Almost every oversized asset on the web comes from measuring the wrong box.

Screen resolutions people actually use

Analytics for the web as a whole is a reasonable starting point, but your own analytics beat it every time. A B2B tool used at desks has a different resolution profile from a consumer site used on phones at night. Check yours before you commit to anything here.

Physical pixels are not CSS pixels

A 4K monitor rarely presents a 3840px CSS viewport. The operating system scales it, so the browser may report 1920 or 2560 while the panel holds four times as many physical pixels. What you lay out against is the CSS viewport; what you supply image pixels for is the physical one. That relationship is the device pixel ratio.

Where to get real numbers

Public aggregate data such as StatCounter’s screen resolution stats shows the shape of the market. Your own analytics shows the shape of your audience. When they disagree, your own data wins without argument.

Mobile website dimensions: what size for mobile site work?

Answer first: design against 360 CSS pixels wide and let the layout expand. That is the practical mobile phone website size floor, and a layout that holds at 360 holds everywhere above it. The size for mobile website work is a width question rather than a height one, because vertical space is scrolled while horizontal space is not.

Two common phrasings of the same question — mobile dimensions website planning, and website size for mobile — both reduce to the same three numbers: 360 pixels as the narrow end you must survive, roughly 390 to 430 pixels as the range most current phones report, and 768 pixels as the point where tablet layouts usually take over. Set the mobile website page size targets from those and stop worrying about individual device models.

Mobile web page dimensions versus device resolution

A phone advertised at 1170 by 2532 physical pixels reports roughly 390 CSS pixels of width to your layout. Confusing the two is the single most common error in mobile web page size planning, and it produces designs built four times too wide. The section on physical versus CSS pixels below explains the ratio.

Mobile viewport widths

Phone marketing names are useless for layout. What matters is the CSS viewport width, which clusters into a narrow band regardless of how the handset is sold.

Design the narrow end

If a layout works at 360px it works at 430px. The reverse is not reliable, because the failures at 360 are wrapping, crowding and overflow — problems that simply do not appear with 70 more pixels to play with. Set your browser to 360 and fix what breaks; you will have fixed the whole range.

The 100vh problem

Setting a hero to 100vh on mobile produces a section taller than the visible area, because mobile browsers include the collapsing address bar in the viewport height. The modern fix is the small, large and dynamic viewport units — svh, lvh and dvh — documented under viewport-percentage lengths. Use dvh when you want the section to track the bar as it hides, and svh when you want it to always fit.

Content width: how wide should the page be?

There is no correct site width, only a correct measure. Measure is the number of characters per line, and it governs whether text is comfortable to read. Everything else is decoration around that constraint.

Web width standards: is there a standard web width?

Answer first: there is no formal standard, but there is a strong convention. Web page width standard practice across modern frameworks and design systems puts the readable content container between 1200 and 1440 pixels, with full-bleed sections breaking out of it where a background needs the whole viewport. When people ask about web width standards they are almost always asking about that container figure rather than the page itself, which is simply the width of the browser.

The reason the convention settled there is legibility rather than tradition: beyond about 1440 pixels a single column of text exceeds a comfortable line length, and the eye loses the start of the next line. That is the same constraint behind the character-count rule below, expressed in pixels instead.

The 60-to-80 character rule

Comfortable reading sits around 60 to 80 characters per line. At a 16px body size that lands near 640 to 720px of text width — which is why a 1200px page nearly always puts body copy in a narrower column inside it, rather than running text the full width. A 1200px line of 16px text is roughly 130 characters and measurably harder to read.

Full-bleed sections inside a contained page

The common modern pattern is a contained content column with individual sections allowed to break out to the full viewport width for backgrounds, imagery and color bands. This gives the visual generosity of a wide layout without ever running text at an uncomfortable measure.

Padding is part of the width

A 1200px container needs horizontal padding or content touches the edge on a 1200px screen. Sixteen to 24px on mobile and 24 to 48px on desktop is typical, which means your true content area at 1200 is nearer 1100. Brief the developer with the content width, not the container.

Framework breakpoints, and why they disagree

Every CSS framework picks its own breakpoints, and they do not match. If you inherit a design built to one set and implement it in another, the layout will look right at the sizes you check and wrong at the sizes between them.

The canonical definitions are published by each project: Bootstrap breakpoints and Tailwind responsive design are the two you will meet most often. The underlying mechanism in every case is the CSS media query.

Content-driven breakpoints beat device-driven ones

The better practice is not to pick breakpoints from a device list at all. Widen the browser slowly and add a breakpoint at the exact width where the layout starts to look wrong. You will end up with three or four odd-looking numbers that are right for your design, instead of five round numbers that are right for nobody’s.

Container queries change the calculation

A component inside a narrow sidebar and the same component in a wide main column have the same problem at different viewport widths, which media queries handle badly. Container queries let a component respond to its own container instead of the viewport, and they are now broadly supported. For component libraries this is a better tool than any breakpoint table.

Mobile-first is a code order, not a philosophy

Writing base styles for narrow screens and layering wider rules on with min-width queries produces less CSS and fewer overrides than the reverse. The MDN responsive design guide covers the mechanics. It is worth doing for maintenance reasons alone, whatever your traffic split.

Above the fold: what height to design for

The fold is not a line, but the first screen still does a disproportionate amount of work. The useful question is what is guaranteed visible before any scrolling on the shortest common viewport.

Design against 600px, not 900px

The shortest common desktop viewport gives you about 600px. If your value proposition and primary action both fit inside 600px of height, they fit everywhere. Designers working on tall monitors routinely produce heroes that push the call to action off the first screen for a large share of visitors and never notice.

Give people a reason to scroll

A hero that exactly fills the viewport can read as the whole page. Letting the next section peek above the fold by 40 to 80px is a small, reliable improvement in scroll depth, and costs nothing.

Image dimensions by placement

These are practical starting sizes for a 1200px content width at 2x pixel density. Adjust the widths if your container is wider; the ratios should stay put.

Serve 2x, design at 1x

Work out the CSS size the image occupies, then export at twice that. A 600px-wide card image wants an 1200px file. Going to 3x roughly doubles the weight again for a difference almost nobody can see, and it is very rarely the right trade.

Crop deliberately, in advance

Responsive layouts crop images differently at different widths. If the subject of a photograph sits near an edge, it will be cut off on some screen. Either crop to keep the subject centered, or set an explicit focal point with object-position so the crop happens where you chose.

File formats and weight budgets

Correct dimensions with the wrong format still produces a slow page. These two decisions are independent and both have to be right.

Format support and characteristics are documented in the MDN image file type guide, and current browser support for the newer formats is tracked at caniuse.

A weight budget that works

Under 150KB for the hero, under 100KB for content images, under 40KB for thumbnails. If a page of images totals more than about 1MB you will feel it on a mobile connection regardless of how correct the dimensions are.

The picture element for format fallbacks

The picture element lets you offer AVIF first, WebP second and JPEG last, and the browser takes the first one it understands. This is the correct way to adopt a new format without abandoning older clients.

Responsive images: srcset and sizes

A single fixed-width image is either too small on desktop or wastefully large on mobile. The browser will pick correctly if you tell it what is available and how wide the image will render.

What srcset does

The srcset attribute on the img element lists the available files with their real pixel widths. The sizes attribute tells the browser how wide the image will be laid out at each breakpoint. With both, the browser downloads the smallest file that will still look sharp on that device.

The mistake almost everyone makes

Supplying srcset without sizes. The browser then assumes the image spans the full viewport width and downloads a file far larger than needed. Guidance on getting this right is at web.dev on serving responsive images, and Lighthouse flags the failure as uses-responsive-images.

How many variants to generate

Three or four is plenty for most images: roughly 400, 800, 1600 and 2400 pixels wide. More variants add build time and storage for diminishing benefit, and most CDNs and CMS platforms will generate this set automatically if you let them.

Lazy loading everything below the fold

Add loading=”lazy” to every image that is not visible on first paint, and never to the hero. Lazy-loading the largest contentful element delays the exact thing being measured.

Width, height, and why your layout jumps

The single cheapest performance fix available on most sites is two HTML attributes.

Set width and height on every image

With the real pixel dimensions present, the browser reserves the correct space before the file downloads, and nothing below moves when it arrives. This does not prevent the image being responsive — CSS still controls display size — it only supplies the ratio.

Or declare the ratio in CSS

Where dimensions genuinely are not known at build time, the CSS aspect-ratio property reserves the space instead. Either approach works; having neither is what causes the shift.

Why it is scored

Cumulative Layout Shift is one of the Core Web Vitals, with a threshold of 0.1. Images without dimensions are the most common single cause. Background at web.dev on CLS and optimizing CLS, and the wider set at Web Vitals.

The hero image and LCP

Your hero is usually the Largest Contentful Paint element. Give it explicit dimensions, do not lazy-load it, preload it if it is critical, and keep it under about 150KB. Those four things fix most LCP problems on marketing sites.

Favicons and app icons

The favicon is a small job that is easy to do incompletely, and an incomplete one produces a blurry icon on somebody’s home screen.

The modern minimum

An SVG favicon, a 180×180 apple-touch-icon, a 512×512 manifest icon and a legacy .ico containing 16 and 32. That is four files and covers effectively everything.

Design for 16 pixels, not for 512

A logo that reads beautifully at 512 is frequently unreadable at 16. Most brands need a simplified mark — an initial or a single symbol — for the small sizes. Check it at 16px on a real tab before you sign it off.

Open Graph and link preview cards

This is the image that appears when your page is pasted into a message, a social post or a chat. It is the most consequential image on many pages and the one most often left unset.

The specification is at ogp.me, and platform-specific requirements are documented by Meta for sharing images. Google’s guidance on how images are handled in search is at Google Images documentation.

Text on share images gets cropped

Different platforms crop the 1.91:1 card differently, and some crop it to a square. Keep any text inside the central square area and nothing important will be lost.

Set a fallback site-wide

Any page without its own share image should fall back to a designed default rather than to whatever image the platform scrapes first. Without a fallback the card is often a logo fragment or a stock photo from the footer.

Describe it in structured data too

Alongside the Open Graph tags, an ImageObject in your structured data tells search engines the canonical image for the page, which matters increasingly for how pages are represented in AI-generated summaries and rich results.

Social platform image sizes

These change more often than anything else here. Treat them as current-and-verify, and check the platform’s own help documentation before a large production run.

Produce three crops, not twelve

Almost every placement above is 1:1, 16:9, 1.91:1 or 9:16. Shoot or design with all four crops in mind, export the four, and you have covered every platform without a bespoke asset per network.

The safe zone

Interface elements sit on top of social images — captions, profile pictures, buttons, progress bars. Keep anything that must be read inside roughly the central 80% of the frame. On 9:16 verticals, keep the top and bottom 15% clear entirely.

Video dimensions

Video follows the same logic as images, with the added constraint that the wrong resolution costs bandwidth on every play rather than every load.

Always supply a poster image

Without a poster attribute the video area is blank until enough data has buffered, which reads as a broken page and contributes to layout instability. The poster should match the video’s dimensions exactly.

Background video is a performance decision

A looping hero video is frequently the single heaviest asset on a site. If you use one, cap it at a few seconds, strip the audio track entirely, and consider serving a static image to mobile instead of the video.

Email dimensions, which follow different rules

Email clients are years behind browsers, and the constraints are stricter and stranger.

Why 600px persists

It fits the Outlook reading pane without horizontal scrolling, and Outlook remains the client you cannot ignore in B2B. The figure has not moved in fifteen years and there is no sign of it moving now.

The Gmail clipping threshold

Gmail truncates messages over roughly 102KB of HTML and hides the remainder behind a link, which typically buries the unsubscribe link and breaks tracking. Keep the HTML lean and host images externally rather than embedding them.

Accessibility constraints on size

Some dimensions are not aesthetic choices. Getting these wrong excludes people and, depending on your market, creates legal exposure.

• Tap targets: at least 44×44 CSS pixels, with spacing between adjacent targets
• Body text: 16px minimum on mobile — smaller triggers zoom on iOS and is hard to read anyway
• Line height: about 1.5 for body copy
• Line length: 60 to 80 characters
• Text must reflow without horizontal scrolling at 320px width and 400% zoom
• Contrast: 4.5:1 for normal text and 3:1 for large text
• Never disable pinch zoom in the viewport meta tag
• Focus indicators must remain visible and unclipped at every breakpoint

The normative reference is WCAG 2.1. The reflow and target-size requirements are the ones most often broken by a design that was only ever checked on a wide screen.

The 320px reflow requirement

Content must be usable at 320px CSS width without two-dimensional scrolling. That is narrower than any phone in the table above, and it is the width at which a wide table or a fixed-width element will fail an audit.

Choosing dimensions for a new asset

A decision order that gets the right answer without a lookup table.

1. Establish where the asset renders and who owns the rules there
2. Measure the widest container it can occupy at your largest breakpoint
3. Multiply by the pixel ratio you intend to support, normally 2
4. Choose one of the four standard ratios and commit to it across the set
5. Export in AVIF or WebP with a JPEG fallback
6. Set width and height attributes, or an aspect-ratio in CSS
7. Generate three or four srcset variants and a correct sizes attribute
8. Add loading=”lazy” unless it is the hero
9. Write alt text that describes the content, not the file
10. Check the result at 360px before calling it done

The mistakes that cause most of the damage

Uploading straight from the camera

A 6000×4000 JPEG at 8MB rendered into a 600px box. The browser downloads all of it. This single mistake accounts for more slow pages than any other.

Measuring the screen instead of the container

Producing 1920px assets for an image box that is never wider than 580px, tripling the weight of every page for no visible gain.

Omitting width and height attributes

Two attributes, and their absence is the leading cause of layout shift and a failing Core Web Vitals score.

Lazy-loading the hero

Delays the Largest Contentful Paint element deliberately, which is the opposite of the intent.

srcset with no sizes

The browser assumes full viewport width and downloads the largest file anyway, so the whole exercise achieves nothing.

Designing only on a large monitor

Produces heroes that push the call to action below the fold on a 768px-tall laptop, which is a large share of real visitors.

No Open Graph image

Every share of the page shows whatever the platform scraped, which is usually a logo fragment.

One favicon at 16×16

Blurry on every home screen and high-density display.

Text at the edge of a social image

Cropped away by the platform, or hidden behind an interface element.

Fixed-height containers around variable text

Works in the design file, overflows the moment a real headline is longer than the placeholder.

Building a dimension standard for a team

Individual numbers are less valuable than a written standard everyone follows. A short document prevents the slow drift into forty bespoke image sizes that nobody can maintain.

What the document should contain

• The container width and horizontal padding at each breakpoint
• The breakpoint list, with the reason each one exists
• The four permitted aspect ratios and what each is for
• Export dimensions for each named placement, at 2x
• The format order — AVIF, WebP, JPEG — and the weight budget per role
• The favicon and app-icon set as a checklist
• The Open Graph default and the site-wide fallback image
• Who is allowed to add a new placement, and how

Enforce it in the build, not in review

Automated image processing in the CMS or build pipeline is far more reliable than asking people to export correctly. If the pipeline generates the variants and strips the metadata, the standard holds without anyone having to remember it.

Audit it twice a year

Social specifications drift, new formats arrive, and the site’s own layout changes. Two hours twice a year keeps the standard true; leaving it for three years produces a document everyone quietly ignores.

Questions about website dimensions

Watch on rendering, weight and performance

Three from Google Search Central that bear directly on how dimensions and file weight affect what search engines see and what users experience.

Standard website width: what the numbers actually are, and why there is no single answer

The most common question here is the width of a web page, and the honest answer is that a website page width standard does not exist as a fixed number — what exists is a content width, a breakpoint set, and a design canvas, and people asking about any of the three tend to use the same words.

The design canvas versus the content area

A website size of 1920×1080 is a canvas — the artboard a designer works on, matching the most common desktop screen. It is not the site’s width. The recommended website width for actual content sits far narrower, typically 1140 to 1440 pixels, with the remainder as margin. Confusing the two is why handoffs produce layouts that stretch uncomfortably on wide monitors.

Typical website dimensions in practice

Ask for typical website dimensions and the working answer is a 1440-pixel design canvas, a 1140 to 1280-pixel content container, and text constrained far tighter still. The average website size by content width has narrowed over the last decade, not widened, because reading comfort caps line length regardless of how large screens get.

The best width for a website is a reading decision

There is no best site width in the abstract. The best website page width is whatever keeps running text near 65 characters a line, which usually means a text column around 680 to 760 pixels even inside a much wider layout. Designers who set the best website width by the monitor rather than by the line end up with text nobody finishes.

Responsive screen size and where the breakpoints go

Responsive web design screen widths are conventionally grouped around 480, 768, 1024 and 1280 pixels, though the useful practice is to set breakpoints where your content breaks rather than at device names. Responsive web page sizes should be driven by the layout failing, not by a list of phones.

Desktop pixel size and the device-pixel trap

Desktop pixel size in CSS is not the same as the hardware resolution. A screen advertising 2560 physical pixels frequently reports 1280 CSS pixels because of scaling, which is why a design built to hardware numbers appears half-size. Always design to CSS pixels and export raster assets at twice the dimension.

Web page design size for specific page types

Landing page dimensions follow the same content-width rules as any other page; what changes is vertical rhythm, since a landing page is scrolled rather than navigated. Splash page dimensions are the one case where the full viewport genuinely matters, because the whole point is filling the screen before anything else loads.

Template sizes

A website template size and a web template size usually refer to the design file’s canvas rather than any published constraint, and website template dimensions vary by the tool that produced them. Check the container width inside the template rather than the artboard, because that is the number that governs how the built page behaves.

Web page specifications worth writing down

The web design dimension list worth handing a developer is short: content container width, text measure, the breakpoints, gutter and margin values, and the asset export multiplier. Designing for web dimensions goes wrong far more often through missing specifications than through wrong ones.

Web screen dimensions change; the constraints do not

Screens keep growing, and the size of an average website’s content area has stayed roughly stable because it is bounded by human reading rather than by hardware. Treat any web page design size guidance as a starting point and let the content decide the rest.

What are the dimensions of a web page, stated plainly

If you want one set of numbers: design on a 1440-pixel-wide canvas, hold content to a 1200-pixel container, keep body text to roughly 700 pixels, and set breakpoints near 480, 768, 1024 and 1280. Those are the average website dimensions in current professional practice, and they will serve almost any project until its content argues otherwise.

What is the width of a web page in practice?

A page is as wide as the browser window; the container inside it is what you control. So the width of a web page is really two numbers — the viewport, which the visitor decides, and your maximum content width, which you decide. Website page width standards are conventions around the second, not rules about the first.

Website page design size versus canvas size

The website page design size that governs how a layout feels is the container, not the artboard. A design delivered at 1920 with content spanning the full width will look stretched on the same monitor it was designed on, because the browser adds its own chrome. Design wide, constrain the content, and specify both numbers on handoff.

Page size in kilobytes, as distinct from page size in pixels

What is web page size is really two questions wearing one phrase, and confusing them wastes a lot of time. Pixel dimensions describe how wide the layout is. Web page size in the other sense means weight — the total kilobytes a browser must download to render the page. Both matter and they are unrelated: a narrow page can be enormous, and a full-width one can be light.

The average size of a web page, and where the weight goes

The average web page size has grown steadily for two decades, and the HTTP Archive’s ongoing measurements — the standard public reference for this — put the median page at a few megabytes, with images and JavaScript accounting for the overwhelming majority. That average is a poor target: it describes what the web does, not what it should do. The useful framing is that average website page size is dominated by a handful of decisions — how many web fonts are loaded, whether images are served at display size in a modern format, and how much third-party script is running. Fix those three and a page lands well under the average size of a web page without anyone touching the design.

Common website widths, and choosing one deliberately

Common website widths cluster tightly because the underlying screen population does. A content container between 1200 and 1440 pixels inside a full-width background is the arrangement most teams settle on, and the best web page width for readable text is narrower still — long-form body copy is easiest to read at roughly 60 to 75 characters per line, which lands around 640 to 760 pixels at typical body sizes. The ideal website width is therefore not one number: a wide container for layout, a narrow measure for text inside it. What size is a website page in practice is a decision about the reading column first and the container second, which is the reverse of how most designs are built.

Frequently asked questions