In-Page Font Resizers are Bad

I’m never one to soften a polemic stance, so here we go.

“In page font resizers are bad.  Bad usability.  Bad accessibility.  Bad design.”
-Tim Arnold 4/4/2014

There, I said it.  I feel so free.

First, let me say that most websites I code have included a font resizer. I’ve been pushing back gently on some of the assumptions about what they accomplish and how successful they are at doing so but I think the time has some to be less gentle and take a more critical look at whether we are doing good or harm when we use these things.

How do they work?

Font resizers generally use JavaScript to change the base font size. If well coded, this means that all text elements (paragraphs, headings, blockquotes, etc.) will resize as well. This is different from how web browser natively “zoom” the page. Increasing only the font size has issues that may cause certain design elements (horizontal navigation is a big culprit here) to break or be harder to use when the fonts they contain become too large to fit. Additionally, any images – including icons which may be important for usability – will not be resized by your average text resizer. As such, many times the site becomes harder to use when text is increased. This is why the browser zoom features, which increase the size of all the elements on the page (more or less proportionally) work the way they do instead of how text-resizers do.

Why is this a problem?

Therefore, we have to be very targeted about what containers are resized by a JavaScript text resizer. Generally, we restrict the size increase to the main content area where it’s most likely that users need the increased size. That’s easier said than done because what constitutes the “main content” is not always clear. Designing sites that let the content stretch out to fill the width and stack blocks of content down the page instead of overly fussy “magazine style” layouts certainly makes resizing the text alone a better experience, but there’s still the issue of images.

Fine, so what’s the solution?

Keep in mind that if we code the site so that the base font size is set to 100% (as we do on most sites these days: or or then the body font size of the website will match the font size that the users have set their computers to use (depending on the font itself, some appear slightly smaller or larger than others). This is especially advantageous because we know for absolutely certain that we have not made a web page that is harder to read than every single font on their computer (Windows menus, default MS Word size, desktop icons, etc.).

But people MUST be able to resize fonts, 100% size isn’t good enough!

I could not agree more! I always prefer to empower users how to resize the text themselves, a skill they can take with them to any website they visit! I often find that people are amazed by how easy it is:  “CRTL +/-“ or “CTRL & mousewheel up/down” in most browsers. I’ve been following Roger Johansson of for years, and here are his thoughts on the subject.

I’ve done a bit of searching and here are some possible models of an alternative approach:

But what if we HAVE to?

The best advice I have, if we must add a resizer, is to add it only to basic article pages where the content simply flows down the page. These are the cases where users will likely spend the most time reading.  On pages like these your resizer should probably be available at the top of the content and not in the header or footer. The best place for them is probably along with any other page-specific tools (share, print, etc.) like on

Why not use both in-page resizer AND instructional solutions?

You probably should. Just be aware of the limitations and possible problems with both and be sure that you are addressing the specific needs of your site visitors.

Are you excited about the epic stuff you just read?

Are you smart, motivated, and eager to solve problems in a collaborative environment? If so, we want you! Join our team!

See Our Current Career Opportunities