Every year a top web trends article comes out. It’s mostly bullshit. But it points to something more interesting in design and perhaps everywhere. We want to know what to do and it’d be nice if it were easy. The design trend article is an extension of that, we don’t want to rebuild the wheel ourselves, we want some guy at Figma to give us some pointers. And that’s fine.

So, instead of giving you an article that says NeoBrutalist backgrounds with animated post-structuralist references is the direction the web is going and taking screengrabs from stuff I like on the Webby Awards, I’m going to try to define the standard web experience.

When I started this project, I was trying to build a flexible starter theme for my custom WordPress sites. I wanted to see what the numbers say about a starting point. The process of designing something then becomes a question of how and why we move away from the center. And the questions came at me in rapid fire.

It got technical, so apologies in advance. The jump links at the top are there for skimming.

Over the years, peeking behind the curtains on the sites I like, I found no real consensus on how to make a site. I did develop my own preferences, but by the numbers, what I found is that the adoption of systems, and how easy they are to adopt, is what determines what the web looks like.

A note on the numbers before I start. Everything below comes from 158,294 websites: the homepages in the Tranco top million that were in English, were actually sites, rendered in a real browser, and were not part of one link farm or an adult or gambling site. I call that the clean corpus. Where a table says “sites” it means a share of those 158,294, or of the subset that had the element in question (not every homepage has an H1). Where a table says “stylesheets” it means a share of the 1,734,591 unique CSS files those sites load, counted once each no matter how many sites share them. Those are different populations and they tell different stories, so I say which one every time. How the corpus was built is its own piece.

TRENDY

This is a bit of a reaction to the obnoxious annual listicle of design trends. There are questions here about how ideas diffuse across cultural artifacts in the age of the internet that I’m not qualified to answer. What I can say is that out of the items I can measure looking at the markup and stylesheets of these websites, it’s hard to say that these “trends” are significant. This is just some shit a designer thinks is cool and has seen a couple of times. And that’s fine. The headline is obnoxious and to me that’s less fine.

Now the list. Figma’s “web design trends 2026” names thirteen. I can only measure five of those with the data that I have with any degree of confidence. So here they are:

On motion: canvas, WebGL, 3D and animation libraries

From the corrected trends probe on 15,001 clean homepages:

15,001 clean homepages, first 400 KB of rendered HTML, tightened patterns (trends_probe2.py).

The most common “motion” on the web is a carousel. Carousels are relatively easy to build by hand and they are easy to make as plugins because of a handful of great JavaScript libraries. What I see in the numbers is that design friction is tied to what we do or don’t see on the web. People do hard things less.

Scroll-triggered animation libraries, GSAP and Lottie together are on about 6% of homepages. Three.js is on four in a thousand. Admittedly these are harder libraries to master and require more assets.

The cookie banner is at 30%, which is six times more common than every animation library combined. This is brought on by necessity, everyone is scared to get sued, people make plugins for that.

Frameworks, themes, stacks, templates

Before we hop into the pixels of it all, I want to put it out there: I like the internet. I like its scaffolding. I’m just trying to wrap my head around the numbers here, and this is the part that explains why things are the way they are.

WordPress comes with most hosting setups as a one-click install. Bootstrap and Tailwind used to be drag and drop, or just pasting a CDN link into your HTML. Now you can spin up either in the terminal with a single line you copy to your clipboard with the click of a button.

IT’S EASY TO START. That’s the point. And then you’re locked into all of their choices. Which is fine…but not really.

domain_tags, one winning framework and CMS per site.

Half the clean web is on Bootstrap. Wix, Squarespace and Webflow together are 1.5% of the Tranco top million, which tells you the builders you see advertised are not where the popular web is built; it’s built on WordPress and on hand-rolled Bootstrap. Both of which are FREE. The 73,656 sites tagged with both Tailwind and Bootstrap are a plugin or a component library bringing the second framework along for the ride.

WordPress is a whole other rabbit hole, but as the most popular CMS very popular themes and plugins also shift the definition of the standar web look in the data. I get into what the Tranco database project has to say about WordPress here.

So what does the standard web look like? Mostly it looks like Bootstrap or Tailwind, Google’s font library, and maybe a few of the popular JavaScript libraries. A lot of what a client thinks of as design is inherited choices from open-source projects like these. In the sense that these frameworks make a lot of the choices, we can think of the web as mostly undesigned.

domain_css_weight, computed_styles and the palette table, clean corpus. The color “system” is each site’s body background, body text and H1 color taken together.

It gets messy

I did a quick count of how many stylesheets a site actually has going at once. On the homepages of these 158,294 sites the browser is running 22.4 stylesheets on average, 703 KB of CSS. That’s the average; it’s a lot worse on the platforms.

domain_css_weight joined to domain_tags, clean corpus; external and inline sheets together.

Twenty-two stylesheets is a lot of surface area for rules to conflict, and it’s exactly how you get 17 breakpoints on one page. Not all of them are min, not all of them are max; the default for any one stylesheet can be the opposite of the one next to it, and you can have conflicting rules inside a single sheet. A Shopify store loads 76 of them. My own site loads 11, five files and six inline blocks, and I thought that was a lot.

Modern CSS in general

I empathize with the design pros evangelizing new ways to make things responsive or faster. In the numbers, though, that change is coming slowly, if it’s coming at all.

Share of stylesheets using each feature, from a 60,000-sheet sample scanned for the signals companion. The year is when the feature became available in every major browser (Chrome, Firefox and Safari), the point after which a site could use it without a fallback.

Units from the 1,734,591 unique sheets the clean sites load; rem beats px on 20,859 of 156,880 sites with CSS; custom properties from the 60,000-sheet sample, median seven variables per sheet that has any.

What a standard looks like

The shame of dropping into a rabbit hole, sometimes, is that you come out with very little to show for it. So for me I wanted to come out with a standard, a baseline: a set of CSS rules that make the averagiest site there ever was. The black t-shirt and jeans of the mid-to-late aughts.

So, according to the numbers, it goes something like this:

• Body. 16px Open Sans on a 24px line-height, black on white. Everything below assumes that 16px base, which is also what the numbers say.
• General headings. Roboto, weight 700, line-height 1.2, sentence case. Nothing uppercase.
• Letter-spacing. None. Normal letter-spacing on every element, nothing tightened, nothing opened up.
• H1. 48px, or 3rem, on a 1.2 line-height.
• H2 and H3. In the numbers these two share a font size: both land on 24px most often. So I bumped the H2 up to 32px (2rem) and kept the H3 at 24px (1.5rem), assuming a body, or base, font size of 16px. That gives 48 / 32 / 24 / 16, a straight 1.5 step.
• Button. Square corners, no border, no shadow, 16px, weight 400, sentence case.
• Breakpoint. One, at 768px, min-width.

The aggregated numbers are not a design choice that any single person made. It’s the intersection of the defaults, and I think that makes it the perfect starting point for a website. It’s serviceable. If you copied and pasted this CSS into your stylesheet, no one would bat an eye at the site. And as a baseline, it lets you change single elements and see the effect they have on the look and feel of the site.

body {
  font: 400 16px/24px "Open Sans", sans-serif;
  color: #000;
  background: #fff;
}
h1, h2, h3 {
  font-family: Roboto, sans-serif;
  font-weight: 700;
  line-height: 1.2;
  letter-spacing: normal;
  text-transform: none;
}
h1 { font-size: 48px; }   /* 3rem   */
h2 { font-size: 32px; }   /* 2rem   */
h3 { font-size: 24px; }   /* 1.5rem */
button, .btn {
  font: 400 16px/1.5 Arial, sans-serif;
  padding: 4px 12px;
  background: #efefef;
  color: #000;
  border: 0;
  border-radius: 0;
  box-shadow: none;
}
@media (min-width: 768px) {
  /* the one breakpoint everyone agrees on */
}

The standard stylesheet: every value is the most common one in the clean corpus except the H2 size, which is the second most common so that it differs from the H3.

Putting it all together by industry

As this project developed I kept adding more passes over the markup and stylesheets. At some point I realized that I was curious about what the sites actually were, and how all of my design questions would change by just adding an industry label.

At first I ran a script against each site’s title and meta description, scoring them against keyword lists, which left over half of the sites with a “general” industry label. Then we did two model runs through Ollama’s hosted API, first Gemma, then DeepSeek. That gave us 28 industry slices.

And because of that, we were able to extrapolate styling patterns across technology, news, gaming, fashion and beauty, and food and drink.

Each card is set in the sector’s most common H1 font, size and weight, its most common body font, size and line-height, and its most common button font, size, weight and radius (computed_styles, clean corpus). Headline copy is invented. The small numbers are the sector’s share of sites with that trait. Scroll sideways.

FONTS

I’ve never made a font. I’ve manipulated them in Photoshop and Illustrator, but making one from scratch is a real talent. So when Google or Adobe just collect them by the dozens and make them easy to include in your site, it’s a no-brainer. So, when talking about our English-language Tranco list that doesn’t include porn or gambling, the most popular fonts are five Google fonts and the operating system’s default font.

Computed body font on 157,837 clean sites that had a body style captured. First family in the resolved font stack.

The ten most common body font families, each card set in the family itself (Google Fonts loaded for this page; system faces render with whatever your machine has). Scroll sideways.

On headings the order shuffles but the cast doesn’t change: Roboto, Open Sans, Poppins, Inter, Montserrat, in that order, lead the H1 list, followed by the system stack and Arial. Nothing else reaches 3,000 sites.

Free and easy wins the web. So much so that 7,812 sites never set a body font at all. Someone shipped a homepage with the browser default. Awesome, why not?

Where the fonts come from:

stylesheet_links hrefs and computed_styles, clean corpus.

Just under half the web loads Google Fonts. About one site in eight runs entirely on fonts the visitor already has, and those are mostly the Bootstrap and Tailwind default stacks (-apple-system, BlinkMacSystemFont, “Segoe UI”…), not a considered choice of Helvetica.

How many fonts does a site use?

Across seven roles (body, paragraph, H1, H2, H3, button, nav), 44.7% of sites use exactly one family. Another 37.2% use two. Only 3.6% use four or more.

157,838 clean sites with computed styles.

Most common pairings

The ten most common H1-over-body pairings on the clean corpus where the two families differ. Heading set in the H1 family, paragraph in the body family. Linux Libertine over a generic sans is MediaWiki’s default skin (243 of the 246 sites with that pairing are MediaWiki installs or Wikipedia mirrors); it renders here only if you have the font.

Roboto over Verdana

The most common H1-over-body pairing is Roboto over Verdana, on 824 sites. It is not a choice anyone made: 97% of those sites run tagDiv’s Newspaper WordPress theme, which ships with Verdana body text and Roboto headings, and two thirds of Newspaper sites never change them. The theme is well designed and only costs 60 dollars. Envato claims the theme has been sold 160K times.

You can see this pattern repeat itself. Third place, Linux Libertine over sans-serif, is MediaWiki’s Vector skin. Like WordPress, you will find MediaWiki among the one-click install options on most hosting services (it used to be called Installatron on cPanel). So even the idea of pairs as a way to distinguish yourself has, for the most part, been left to other designers up the food chain. Long gone are the days of people changing the CSS on their MySpace.

Headings and body, role by role

The same measurements for each role, so you can compare them. The H2 and H3 both land on 24px most often; what separates them on the median site is weight and the ratio to the paragraph, not a step on a scale.

computed_styles, clean corpus, one element per role per site. The tabs below carry the full size bands, fonts, weights, line-height and letter-spacing for each role.

Fluid type and clamp()

The question of whether anyone uses clamp() is born out of the slight discomfort of having to learn a new style. The answer to the question is much more interesting. 2% of the 1.7 million stylesheets powering the 158K corpus use clamp(). 27% of websites have clamp() on their site. It’s coming from larger organisations’ assets: YouTube’s embedded player, the WordPress block library, app build bundles. Six files explain most of it.

Sheets say no, sites say yes

Sheets: 1,734,591 unique stylesheets by content hash. Sites: 156,880 clean sites with any CSS captured, 1,414 of the 158,294 had none. A feature that lives in one popular shared sheet scores low on the first and high on the second.

Who put it there

Of the 42,852 sites with clamp() somewhere, most got it from one of six files they never opened. One row per file, host dropped and versions merged, so WordPress’s block library counts once across every site that serves its own copy.

42,852 clean sites with clamp() in any stylesheet; a site can appear in several rows. After row ten nothing reaches more than 1.1% of clamp() sites; the tail is WordPress plugins, app bundles and generic file names. The two YouTube player versions alone are the only clamp() on 5,587 sites, which makes an embedded video the single biggest reason a site “uses clamp()”. The inline row is not all hand-written: Wix and most page builders inline their platform CSS, and the Next.js and LiteSpeed rows are bundles, so the share a site’s own designer wrote is somewhere under the 12.9% in row 3 of the ladder below.

The platform talks, the headline doesn’t

Split by platform, the first two numbers swing with whoever ships the CSS. The third one, the share of homepages whose H1 computed to a fractional pixel size like 43.2px, barely moves.

Clean corpus. clamp() anywhere and on font-size: share of each platform’s sites with CSS captured. Fractional H1: share of each platform’s sites with an H1 captured; 14,623 of 113,043 overall (12.9%). A fractional pixel size also comes from a plain rem or em value, so the green bar measures headings sized in anything but hard pixels, not strictly fluid ones. Shopify puts clamp() on font-size on 84.7% of stores and its homepage H1s are no more fluid than anyone else’s.

The same question, seven answers

Rows 2 and 3: of 156,880 clean sites with CSS. Rows 4 to 6: of 155,878 with a font-size declaration. Row 7: of 113,043 with an H1. Row 3 drops WordPress core, theme and plugin files, Shopify’s cloud sheets and the Wix, Squarespace and Webflow static hosts, but keeps inline styles and same-origin bundles, so it is a ceiling for hand-written clamp(), not a count.

The silver lining here is that if you make something modern and useful, people use it and you end up having an outsized influence. Not counting inline, the top six clamp() stylesheets reach 20,900 sites, when counting for overlap.

The less gracious reading is that very few independent designers are using clamp(), and that “design progress” is just moving the goalposts by elite tech design cadres. This allows them to maintain their position at the top of the hierarchy based on how well they know the new rules. A design bureaucrat, if you will.

But that is not the argument I’m making at the moment because, obviously, screens have gotten big as hell and there should be a good way to deal with that in browsers.

BUTTONS

Buttons are some of my favorite things to design. With pseudo-classes and basic animations you can get a lot of personality out of plain CSS, and even more if you’ve got some JavaScript under your belt. So the button can tell us a lot about the creativity of the internet.

Buttons were a little tricky to count. In my experience most buttons are actually styled hyperlinks, and I didn’t want header, nav, footer or cookie-bar buttons in the numbers; a newsletter submit and an Accept All are buttons, but nobody designed them for this page. So a button here is anything with a background color and some padding, or a border and some padding, and I took the first visible one between the header and the footer on every site, re-rendered from the stored markup and stylesheets. That found a button on 94,424 of 157,549 sites. The other 63,125 had nothing that qualified: 17,714 had nothing button-like on the page at all, 13,401 had only bare text links wearing a button class, and 15,943 had buttons only in the header, footer or cookie bar. The numbers suggest the button is the most diverse element on the page: the 94,424 buttons fall into 81,979 distinct styles, and 78,417 of those styles exist on exactly one site.

Here are the most repeated buttons found on the corpus between the header and the footer. The most common one is the one nobody styled.

The ten most repeated button styles, by exact computed fill, text color, radius, size, weight, padding, border, case, shadow and letter-spacing (font family not part of the key), each re-rendered with those values on its group’s most common page background. The browser default is the only one above half a percent of the 94,424.

Designed-button pass over the clean corpus, 94,424 buttons; hover, focus and transition figures from a stylesheet walk that tests each pseudo-class rule’s selector against the chosen button.

Color

Fill color converted to HSL; anything under 15% saturation that is not pure white or black is a neutral. The 12,301 outline buttons have no fill to classify. Blue is the color of the web’s button; add teal and it is 29.3% of fills, more than red, orange and yellow together.

Padding and font size

94,424 designed buttons. Padding as computed; the median is 9.9px vertical and 20px horizontal, and the median button is 45px tall. The single most common font size is 16px (29.0%), then 14px (19.0%) and 18px (10.5%).

So the button of the web is blue or white, 16px, sentence case, about 10px by 20px of padding, with a hover rule that swaps its background color over 0.3 seconds. One in five has no fill at all, or a fill you can’t see. The personality I was hoping to find is there, but it’s rare: fewer than one in twelve buttons moves when you hover it, one in a hundred animates, and the single most repeated button on the web is the one the browser drew because nobody got to it.

WHITE SPACE

I work with architects, and white space is an appealing concept to them. It gets batted around, but usually they’re talking about larger divs having top and bottom padding or margin. We’re going to concern ourselves with text spacing.

Line height

It’s the one spacing value everybody has an opinion on.

Clean sites where both values resolved to pixels. The body line-height is the browser default normal on another 28,974 sites (18.4% of bodies), which works out to about 1.2 in most fonts.

So the body is 1.5 and the headings are 1.2, give or take. Both numbers are exactly what Bootstrap ships (line-height: 1.5 on the body, 1.2 on headings), and the distribution shows it: 64.5% of bodies sit between 1.4 and 1.6, and the single most common H1 ratio is exactly 1.2 on 24,060 sites, with 1.0 (16,325) and 1.1 (15,827) behind it. On paragraphs the band is wider: 20% run at 1.6 to 1.8, which is the “airy blog” setting, and 7.6% of paragraphs run under 1.2, which is cramped.

Letter spacing

Almost nobody touches it, and the higher up the page you go the more they do.

computed_styles letter_spacing per role, clean sites with the element captured. Tightened is any negative pixel value, opened up any positive one.

Letter-spacing is a headline habit. One H1 in seven is tightened, usually by about -0.02em, and the rate falls with every level until body text, where 95% of sites leave it alone. When it is opened up it’s by 1px or less. The nav, which the all-caps, spaced-out portfolio nav would lead you to expect is the element with the most letter-spacing on the page, is one of the least: 93.8% at normal, and only 1.7% of navs are uppercase at all.

BREAKPOINTS

I love it when I’m talking to a prospective client and they raise their eyebrow and ask me if the site is going to be responsive. It’s a can of worms they’re about to open, and it usually ends with their eyes glazed over. For me the easiest way to show it is to change the width of a browser in front of them. I think the backbone of responsive design, at least in a way that is easily explainable, is the breakpoint.

Resizing a browser window across the breakpoints of one site. Scroll sideways for the three widths. I made this little page to show you the way breakpoints work. The movie is Le Cercle Rouge; watch the Melville stuff, this and Army of Shadows are so cool.

I’ve been working on websites since 2014 or so, and the evangelizing class of web design was pushing for mobile-first design even then. Back then I was just picking up Bootstrap templates or modifying the CSS of a WordPress site in the customizer or a child theme’s stylesheet. When you work like that, the defaults are already set and you’ll end up seeing a lot of conflicting style rules. Many of them were born from the fact that multiple stylesheets were being resolved for a single page.

Mobile sites have the easier layouts. Most of it is stacking elements on top of each other. If you are using a grid or display flex, you’re down to two or three columns at most. It took me years to figure out why it was better to have media queries for the wider views and leave the default rules for mobile.

Still, 12 years out, I run into issues caused by other people’s stylesheets and breakpoints. It gets real messy real fast. So then the question becomes: what are the most common breakpoints? If I were to write a complete stylesheet from scratch, where should my breakpoints be?

148,616 clean sites whose stylesheets contain at least one width media query, out of 156,880 with any CSS captured. Counting occurrences instead of sites, 768px min-width appears 3,479,053 times and 767px max-width 2,917,948 times across the 1,734,591 unique sheets. One gap: Tailwind 4 writes its queries in range syntax (width >= 48rem), which the parser does not count, so the Tailwind cluster is undercounted by however many sites are on version 4.

768 is the iPad’s portrait width from 2010. It’s Bootstrap’s medium breakpoint, and it turns out to be Tailwind’s too, and it is the only breakpoint the two share: Bootstrap runs 576, 768, 992, 1200 and 1400; Tailwind runs 640, 768, 1024, 1280 and 1536 (written in rem, and 48rem is 768px).

That’s why it’s in 87% of sites’ CSS and nothing else comes close: it’s the one width where the two biggest frameworks and the iPad all coincide. The next cluster, 992 and 1200, is Bootstrap’s grid. 640, 1024 and 1280 are Tailwind’s. 1440 shows up in about one site in five and 1920 in one in ten, but neither comes close to the top of the table. Nothing above 1280 is a convention. The web still stops thinking about layout at 1200 pixels.

Then there’s the distinction between min and max, and that’s really about the default. min-width: 768px means these rules apply at 768 and wider, so tablet and up, and everything outside the query is the default, which is mobile. max-width: 767px is the same boundary from the other side: desktop is the default and the rules subtract as the screen shrinks, hide the sidebar, collapse the nav, un-float the columns. Why it matters: with min-width the phone, the weakest device, applies the least CSS and nothing ever has to undo anything. With max-width the phone applies the most CSS and most of it is overrides. And at a width nobody tested, a mobile-first site falls back to the simple layout and a desktop-first site falls back to the complex one. That’s also why 767 and 768 are one breakpoint in the table above: mobile-first authors write 768 min, desktop-first authors write 767 max.

How many breakpoints does a site have? More than you’d think.

148,616 clean sites with width media queries. Median 17 distinct widths. Every stylesheet a site loads is counted, including the slider plugin and the cookie banner.

It’s the clearest measure in this whole study of how little of a site’s CSS the site’s “designer” wrote. A lot of it is just handed down by a built-in framework or a vendor’s specific stylesheet. In this sense responsiveness looks and behaves like an obligation put upon website owners, and we just take the easiest way out to solve the problem, time and again. So a site becomes a patchwork of stylesheets, and the designer’s job is to tape the seams, so to speak.

Mobile-first versus desktop-first, measured by whether a site’s media queries are mostly min-width or mostly max-width:

148,616 clean sites. “Mostly” means one direction outnumbers the other by at least 1.5 to 1. Counting raw queries, min-width wins 72,555 sites to 74,112 for max-width, a dead heat.

We’re 15 years out from Web 2.0 and the mobile-first design evangelism, and in that time no real consensus has been reached. Mostly min-width and mostly max-width are about the same. That 23% with both used evenly, those are my favorite. The duct tape warriors. The only thing we can say is that 91% of sites have a mix of breakpoints, and that’s alright. Like I said before, it’s messy out there.

CONCLUSION

I started off this piece being a bit of an asshole to the Figma writer churning out trends pieces for the year. I think it’s wonderful that we have some new interesting sites out there that are getting recognized. So, to reiterate, the collection of all this data isn’t about saying “nuh-uh” to the idea that something is growing in popularity.

There’s this eye roll from deep in my soul that says the internet is stagnant in its design, and that there is a monopoly on the way it looks, and what it is comes from institutions that need ubiquity, like YouTube. And I think that’s a standard thing, if not a hack thing, to say: the internet is boring. It looks the same.

It’s not wrong though; the data supports it. It is in fact very homogenized, because that’s the easiest way to build sites at the speed and scale necessary for running businesses. In doing the research, we can point to interesting open source projects, like Tailwind, and large orgs, like YouTube, building out infrastructure to make themselves easy to apply. These types of projects have a fundamentally deeper effect on what the web looks like at the baseline than the trends article.

Right now the web page is a base 16px font, and we have rules about the relationship between headings, font sizing, letter-spacing and line-height based on the data. Small changes across these attributes distinguish the work. We can map our choices against the industry standard cards we created earlier.

For me, I’m imagining rolling my own underscores theme with the standard page’s measurements, modernized: rem for everything up to 768px, and clamp() for everything above it. Best practices for clamp() have yet to be calculated. Maybe next week.

On the horizon, the most interesting question I’m left with is what LLMs are going to do to the standard page. They’re easier to interact with than frameworks, content management systems and the rest. The barrier to entry to making websites has just dropped significantly. Part of me is excited. I hope more people will stretch in their design choices now that it’s so much easier to get the basics down.

But that sick little voice is telling me that next year, when I run this project back, we’re just going to see a new footprint: the Claude or ChatGPT website footprint. And that’s fine.