Many a time, we use tools to convert
px to a relative unit such as
rem. Yet, we get weird-looking decimals like
0.9375rem. Problem is, afterward, it’s hard to know if
14px, or something else.
The 62.5% font-size trick helps us use a pixel value along with a relative unit. This way, we do without conversion tools and still have better readable values.
Why Convert px to em or rem?
If it’s okay to let users decide at what font size it’s best for them to read a webpage then we need to use relative font units.
Of course, with
px, users can enlarge text by zooming in or out. Yet, changing the browser’s font size helps them set it once and avoid zooming each time they visit a webpage.
rem makes the element responsive to the user’s preference.
Setting the Root Font Size to 62.5%
Humans are better at thinking in tens since we are familiar with the decimal (base-10) number system.
1rem were equal to
10px in some alternative reality, we could easily translate any pixel amount to rems by dividing it by 10.
12px would be expressed as
24px would be
2.4rem, and so on. We would no longer need to divide by 16.
But the root font size of browsers isn’t
16px! So how can we make the root font size be
10px? Well, one way we could do this is by setting the root font size in pixels:
While this does work, it also locks users into a hardcoded root font size of
10px. If they later change their font size preferences in their browser settings, the root font size on your site won’t update.
Our only other option is to use percentages. Since
16px, we can set the root font size to be this percentage:
/* 62.5% of 16px browser font size is 10px */
/* 1.2 * 10px = 12px */
If we were to just stop here, the text on our page would be illegibly small at a mere
We can fix this by setting the font size of our body to be
1.6rem, which scales us back up to an effective font size of
16px for all visible text on the page:
/* 10px */
/* 16px */
Why 62.5% Font Size Works
At this point, you may be a little suspicious. We scaled the root font size down, but then we scaled it back up for the body—doesn’t that defeat the whole purpose of scaling the root font size down in the first place?
The important thing to understand is that the root font size (on the html element) need not be the same as the font size on the body element.
In this case, we have a root font size of
10px because we scaled the html font size down to 62.5% of the browser’s font size, but we did this solely for the convenience of translating pixels into rems.
Our body font size—all of the visible text on the page—is still scaled back up to an effective font size of
16px so that it matches the browser’s font size.
These are just two ways of looking at the same equation. Before, we would have had to perform this calculation to express a target pixel font size in rems:
12px in rems: 12 / 16 = 0.75rem
But here, we can express 12 as a multiple of 10 without changing the equation:
12px in rems: (1.2 × 10) / 16 = 0.75rem
We can then group the 10 with the 16 and simplify that fraction:
Grouped: 1.2 × (10 / 16) = 0.75rem
Simplified: 1.2 × 0.625 = 0.75rem
Notice that the right-hand side of the equation is still the same as it was originally, but the left-hand side expresses the target font size conveniently as a multiple of 10.
This is just a more formal way of arriving at the same result that we derived intuitively.
In short, the 62.5% trick just makes it easier to express pixels in rems.
Is This Accessible?
So far, we have only considered the case where the browser has the default root font size of
16px. But what if a user changes their browser’s font settings?
Well, recall that we have set the body font size to be
1.6rem. So we really have this equation:
html font size = 62.5% of browser font size (0.625)
body font size = 0.625 × 1.6rem = 1 (i.e., 100% of the browser font size)
Notice that we really don’t care what the browser font size is. Since 1.6 and 0.625 are inverses of each other, they cancel out in this equation, yielding the browser’s font size every time.
Our CSS will always respect the user’s font size preferences.
Shall We Test Our New Set-up?
Let’s be more specific and come up with an imaginary scenario. Suppose a visually-impaired user wants to visit the webpage you have designed.
To be able to see everything more clearly, they decide to make some adjustments to the browser’s font-size in advance.
For example they might set it to
18px, a bit bigger than the standard size (
It is now time to examine the following code snippet closely to witness the functionality of the HTML and body-oriented set-up from the perspective of this individual.
As the developer of this webpage, you chose ‘62.5%‘ for the HTML and ‘1.6rem‘ for the body as the initial font size.
But remember that the browser’s font-size determined by the above user is now
How is it going to work out? Will this person be upset and leave the page feeling frustrated or will they keep surfing the webpage without trouble?
Here’s the answer.
Once the browser’s font-size is chosen as
18px by the user, the font-size will instantly be re-calculated as
11.25px (18px * 62.5%) by the system.
As a result, the value for the body will be 18px (1.6rem * 11.25px) just the way it is requested by that specific user.
So this person will not be negatively affected by the situation just because they wish to see the font-size bigger than the standard version.
The good news is that all of these will be re-calculated automatically. And thanks to the percentage and rem-oriented set-up, the text on the webpage will be more responsive and user-friendly.
Let’s look at an example. Assume that we have this CSS:
Now, suppose a user goes into their browser settings and sets their preferred font size to
20px. Does this create any problems for us? Let’s see how the math pans out for body text:
Browser font size: 20px
html font size: 0.625 × 20px = 12.5px
body font size: 1.6rem = 1.6 × 12.5px = 20px
The body font size equals the browser font size, as expected.
What about the
4.8rem-sized heading? After the user sets their base font size to
20px, this heading will have a computed font size of
Heading font size = 12.5px × 4.8rem = 60px
This may seem strange since we actually wanted
4.8rem to equal
48px, but remember: That’s only true when we assume the root font size is
16px, which isn’t the case here.
If a user increases their preferred font size, all rem-based font sizes will scale up proportionally.
So in this case, it’s actually good that the heading font size is
60px because it means that the ratio between the h1’s size and the browser font size was preserved:
Before: 48px ÷ 16px = 3
After: 60px ÷ 20px = 3
Is This Method Bullet-Proof?
Despite the fact that the method that uses the root size ‘62.5%’, since it’s specifically a percentage value and the rem-based preference in the body section gives us a chance to play around with the general font-size dynamically, it is also not risk-free and you should use it cautiously
For instance, it may lead to some problems when ‘
em‘ values are preferred instead of ‘
Plus, this technique only resizes text. So you will need to use some other tricks (for example, when dealing with the size of the images).
That said, overriding the root font-size is still a widespread practice preferred by many developers around the world and it can be handy if used carefully.
Rems are great for responsive font sizing, but sometimes you may find the math a little inconvenient if you need to translate odd numbers into rems or work with very large numbers.
In that case, you may find it helpful to use the 62.5% font size trick as described in this article since it allows you to think in the familiar base-10 system while using rems.
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?