How are the points in CSS specificity calculated

The current Selectors Level 4 Working Draft does a good job of describing Specificity in CSS:

Specificities are compared by comparing the three components in order: the specificity with a larger A value is more specific; if the two A values are tied, then the specificity with a larger B value is more specific; if the two B values are also tied, then the specificity with a larger c value is more specific; if all the values are tied, the two specifities are equal.

This means that the values A, B and C are completely independent of each other.

15 classes doesn't give your selector a specificity score of 150, it gives it a B value of 15. A single A value is enough to overpower this.

As a metaphor, imagine a family of 1 grand parent, 1 parent and 1 child. This could be represented as 1,1,1. If the parent has 15 children, that doesn't suddenly make them another parent (1,2,0). It means that the parent has an awful lot more responsibility than they had with just 1 child (1,1,15). ;)

The same documentation also goes on to say:

Due to storage limitations, implementations may have limitations on the size of A, B, or c. If so, values higher than the limit must be clamped to that limit, and not overflow.

This has been added to tackle the problem presented in Faust's answer, whereby CSS implementations back in 2012 allowed specificity values to overflow into each other.

Back in 2012, most browsers implemented a limitation of 255, but this limitation was allowed to overflow. 255 classes had an A,B,c specificity score of 0,255,0, but 256 classes overflowed and had an A,B,c score of 1,0,0. Suddenly our B value became our A value. The Selectors Level 4 documentation completely irradiates that problem by stating that the limit can never be allowed to overflow. With this implementation, both 255 and 256 classes would have the same A,B,c score of 0,255,0.

The problem given in Faust's answer has since been fixed in most modern browsers.


Pekka's answer is practically correct, and probably the best way to think about the issue.

However, as many have already pointed out, the W3C CSS recommendation states that "Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity." So the geek in me just had to figure out just how large this base is.

It turns out that the "very large base" employed (at least by the 4 most commonly-used browsers*) to implement this standard algorithm is 256 or 28.

What this means is that a style specified with 0 ids and 256 class-names will over-ride a style specified with just 1 id. I tested this out with some fiddles:

  • 255 classes are not enough to override 1 id

  • ...but 256 classes are enough to override 1 id

  • ...and 256 tag-names are enough to override 1 class-name

  • ...but, alas 256 ids are not enough to override 1 inline style (Updated 2012/8/15 -- you'll have to use !important)

So there is, effectively, a "point system," but it's not base 10. It's base 256. Here's how it works:

(28)2 or 65536, times the number of ids in the selector

  • (28)1 or 256, times the number of class-names in the selector
  • (28)0 or 1, times the number of tag-names in the selector

This isn't very practical for back-of-the-envelop exercises to communicate the concept.
That's probably why articles on the topic have been using base 10.

***** [Opera uses 216 (see karlcow’s comment). Some other selector engines use infinity — effectively no points system (see Simon Sapin’s comment).]

Update, July 2014:
As Blazemonger pointed out earlier in the year, webkit browsers (Chrome, Safari) now appear to use a higher base than 256. Perhaps 216, like Opera? IE and Firefox still use 256.

Update, March 2021:
Firefox no longer uses 256 as a base.


I am currently using the book CSS Mastery: Advanced Web Standards Solutions.

Chapter 1, page 16 says:

To calculate how specific a rule is, each type of selector is assigned a numeric value. The specificity of a rule is then calculated by adding up the value of each of its selectors. Unfortunately, specificity is not calculated in base 10 but a high, unspecified, base number. This is to ensure that a highly specific selector, such as an ID selector, is never overridden by lots of less specific selectors, such as type selectors.

(emphasis mine) and

The specificity of a selector is broken down into four constituent levels: a, b, c, and d.

  • if the style is an inline style, then a = 1
  • b = the total number of id selectors
  • c = the number of class, pseudo-class, and attribute selectors
  • d = the number of type selectors and pseudo-element selectors

It goes on to say that you can often do the calculation in base-10, but only if all columns have values less than 10.


In your examples, ids are not worth 100 points; each is worth [0, 1, 0, 0] points. Therefore, one id beats 15 classes because [0, 1, 0, 0] is greater than [0, 0, 15, 0] in a high-base number system.


Good question.

I can't tell for sure - all the articles I manage to find avoid the example of multiple classes, e.g. here - but I assume that when it comes to comparing the specifity between a class selector and an ID, the class gets calculated with a value of 15 only, no matter how detailed it is.

That matches my experience in how specificity behaves.

However, there must be some stacking of classes because

.a .b .c .d .e .f .g .h .i .j .k .l .m .n .o

is more specific than

.o

the only explanation I have is that the specificity of stacked classes is calculated only against each other but not against IDs.

Update: I half-way get it now. It is not a points system, and the information about classes weighing 15 points is incorrect. It is a 4-part numbering system very well explained here.

The starting point is 4 figures:

style  id   class element
0,     0,   0,    0

According to the W3C explanation on specificity, the specificty values for the abovementioned rules are:

#a            0,1,0,0    = 100
classes       0,0,15,0   = ... see the comments

this is a numbering system with a very large (undefined?) base.

My understanding is that because the base is very large, no number in column 4 can beat a number > 0 in column 3, the same for column 2, column 1 .... Is this correct?

I'd be interested whether somebody with a better grasp at Math than me could explain th numbering system and how to convert it to decimal when the individual elements are larger than 9.