Hello Sunil

Elevate Your Design with the 62.5% Font Size Mastery

Many a time, we use tools to convert px to a relative unit such as em or rem. Yet, we get weird-looking decimals like 0.9375rem. Problem is, afterward, it’s hard to know if 0.9375rem is 13px, 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.

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.

So converting px to em or rem makes the element responsive to the user’s preference.

Humans are better at thinking in tens since we are familiar with the decimal (base-10) number system.

If 1rem were equal to 10px in some alternative reality, we could easily translate any pixel amount to rems by dividing it by 10.

So 12px would be expressed as 1.2rem, 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 10px—it’s 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:

html {
  font-size: 10px;

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 10px is 62.5% of 16px, we can set the root font size to be this percentage:

html {
  /* 62.5% of 16px browser font size is 10px */
  font-size: 62.5%;

.some-element {
  /* 1.2 * 10px = 12px */
  font-size: 1.2rem;

If we were to just stop here, the text on our page would be illegibly small at a mere 10px.

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:

html {
  /* 10px */
  font-size: 62.5%;

body {
  /* 16px */
  font-size: 1.6rem;

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.

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.

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 (16px).

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.

html {
    font-size: 62.5%;
body {
    font-size: 1.6rem;

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 18px, not 16px anymore.

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:

html {
  font-size: 62.5%;
body {
  font-size: 1.6rem;
h1 {
  font-size: 4.8rem;

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 60px:

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

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 ‘rem‘ values.

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.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Similar articles you may like

Sunil Pradhan

Hi there đź‘‹ I am a front-end developer passionate about cutting-edge, semantic, pixel-perfect design. Writing helps me to understand things better.

Add comment

Stay Updated

Want to be notified when our article is published? Enter your email address below to be the first to know.

Sunil Pradhan

Hi there đź‘‹ I am a front-end developer passionate about cutting-edge, semantic, pixel-perfect design. Writing helps me to understand things better.