By · Updated

CSS Size Calculator

Raw, Minified and Gzipped Stylesheet Size, and Whether It Blocks First Paint

No ratings yet

OneTask is free, with no sign-up, and built by one person.
If this tool saved you time, a coffee helps keep new ones coming.

How the CSS Size Calculator works

This CSS size calculator shows the cost of a stylesheet over the wire. CSS blocks rendering: the browser will not paint anything until every stylesheet in the head has arrived and been parsed. Paste your CSS to see what it actually costs on the wire — the minified size, the gzipped size the server sends, and whether that fits inside the first round trip — along with the rule, selector and declaration counts that hint at how much of it is dead weight.

CSS size calculator: raw, gzip and brotli

The size that matters is the compressed one. Servers gzip or Brotli text before sending, and CSS compresses extremely well because it repeats the same property names and values over and over; a 100 KB source file commonly goes out at 15 KB. The calculator minifies your paste — strips comments and whitespace the way a build tool would — and then gzips it in the browser with the CompressionStream API, so the figure is the real byte count a browser downloads, not an estimate.

The 14 KB line. A new connection starts with a small congestion window, about ten packets or roughly 14 KB, before the server has to wait for an acknowledgement. Everything in that first window arrives in one round trip; anything beyond it costs at least one more. On a mobile connection a round trip can be 100 to 300 ms, so a stylesheet that is 15 KB compressed paints measurably later than one that is 13 KB. That is why the usual advice is to inline the rules the first screen needs — the critical CSS — directly in the HTML, and load the full stylesheet without blocking, so the first paint happens in that first round trip.

Reading the counts. Rule and selector counts do not affect download time much once compressed, but they tell you about parse cost and about waste. A hand-written stylesheet for a content site has a few hundred rules. A framework shipped whole has several thousand, most of them never matched against any element on the page. Chrome's Coverage panel shows the unused percentage on a real page; over 80% unused is common and is what purge tools and per-route splitting fix. Many !important declarations point to a specificity war, which usually means duplicated rules that could be consolidated. @import is the one thing to remove on sight: the browser cannot discover the imported file until it has downloaded and parsed the importing one, so each level adds a full round trip to the blocking chain.

Fonts and media queries. @font-face rules are cheap in bytes but each one that the page uses triggers a font download that blocks text rendering until it arrives or times out. Media queries cost nothing when the condition is false, but the stylesheet still has to download; if a large block of print or wide-screen CSS is only relevant to some users, moving it to a separate file with a media attribute lets the browser fetch it without blocking.

FAQ

Why is the gzip size so much smaller than the minified size?

Because CSS is repetitive. Property names like margin, padding and background-color appear hundreds of times, and gzip replaces each repeat with a short back-reference. Ratios of 5:1 to 8:1 are normal, which also means that removing whitespace matters less than it looks — gzip already handles most of it — and removing unused rules matters more.

Does Brotli make it smaller still?

Usually by another 10 to 20 percent for CSS, because Brotli ships with a built-in dictionary of common web text. The Gzip / Brotli Size Comparison tool on this site shows both figures.

Should I inline all my CSS?

Only when the total is small, under about 14 KB compressed. Inlined CSS is not cached between pages, so a large inlined stylesheet is re-downloaded on every navigation. The usual pattern is a small inlined critical block plus one cached external file.

Is my stylesheet too big?

Under 20 KB compressed is comfortable for a content site. 50 KB is where a single render-blocking file starts to show up in Largest Contentful Paint on mobile, and anything over 100 KB compressed is almost certainly carrying rules the page never uses.

Why does the minified size differ from my build tool's output?

This minifier only strips comments and whitespace. Real minifiers also shorten colours, merge duplicate rules and drop redundant units, so expect theirs to be a few percent smaller. The gzip size difference is smaller still.

See also: all Dev Utilities tools, Formatters & Validators, Data & Encoding, Security & Identifiers, SEO, Accessibility, AI.

Related tools