Never use a number or currency formatting library again!

Contents

1. Intro
2. Number Format
3. Currency Format
4. Units Format
5. Summary

Intro

Reducing dependencies that you ship with your frontend is always a good thing!
If you are using a number or currency formatting library, check it out on Bundlephobia and see how much time and bytes it adds to your application.

All this can be done with a new cross browser API! Intl.NumberFormat

Number Format

Formatting numbers is hard! Adding thousand separators, decimal places and so on.
Never mind internationalization too! Some languages use comma separators, some dot separators and thats only the start!

Enter Intl.NumberFormat.

The Intl API has some really helpful methods but we are going to focus on number formatting in this blog.

Let's jump straight in with an example:

const numberFormat = new Intl.NumberFormat('ru-RU');
console.log(numberFormat.format(654321.987));
// → "654 321,987"

Here we have specified the locale to be russian, however if you use the constructor without passing a locale it will auto detect based on the users browser.
Meaning it will change depending on the users preference, localising to your users:

const numberFormat = new Intl.NumberFormat();
console.log(numberFormat.format(654321.987));

This is supported across all browsers now, including Safari!

But we can take it even further...

Currency Format

Not only can we format numbers this way, but we can also support currencies too.
This is relatively new support across browsers, so what out of Safari versions your users are using.

This works great for formatting numbers:

const number = 123456.789;

console.log(new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(number));
// expected output: "123.456,79 €"

There is support for every currency I could think of.

Remember this won't do any currency conversions between them, only format how they are displayed.

Units Format

I didn't know this until researching this blog. But you can even format units!!
This isn't yet supported on Safari, so again check the browser compatibility.

new Intl.NumberFormat('en-US', {
    style: 'unit', 
    unit: 'liter', 
    unitDisplay: 'long'
}).format(amount);
// → '3,500 liters'

There are an enormous list of supported units, including speeds and loads more.
It even allows you to format percentages, which I've always found a pain.

new Intl.NumberFormat("en-US", {
    style: "percent",
    signDisplay: "exceptZero"
}).format(0.55);
// → '+55%'

Summary

The Intl.NumberFormat is a really powerful tool in the arsenal of web developers!

No need to add an additional dependencies to your application. Increase speed and international support with the Intl API!

Happy Building!

Comments

[Fadi Khadra]

Wish we had something similar for dates 🤣

[Jordan Finneran]

It won't translate into other languages but this element from GitHub will help with common date display tasks
jordanfinners.dev/blogs/5-github-e...

[Jordan Finneran]

I've just checked and there is also this developer.mozilla.org/en-US/docs/W...

Which would do this for dates! 😀

[Fadi Khadra]

This is neat! 👌

[ChristophHeinemann]

.toLocaleDateString

[Ian Wijma]

I knew Intl was awesome, but man, looking at the docs of it, I see so many functions that I've written myself before.

[Christos Litras]

It depends on the size and the importance of the project and what versions of browsers that project needs to keep supporting. If we have a project that thousands or millions of users use in a daily basis, then most likely we'll have to deal with old browsers that won't have built-in support for Intl.NumberFormat API.

In a perfect universe where all people would have browsers that would support latest features, that would be awesome; but if we ditch backward compatibility and don't deal with missing APIs, then we'll end up with user's frustration, countless hours of debugging dealing with such issues and users moving away to other apps/platforms that will be able to see the actual numbers and not errors or empty strings.

Also, making applications using a native feature if it's available and fallback to a library if the feature is not available, will create inconsistency regarding data formatting and presenting.

If we have statistics regarding the userbase and the browsers they're using, the team can make conclusions and decide which minimum browser versions the platform/app will support and always detect these features and if not available display messages to the users that they have obsolete browsers/platforms and they need to update.

PS: Never use floats to store currency values, always use integers to strore the prices as cents!
PS2: caniuse.com/NumberFormat is always a nice way to check for features and browsers compatibility so we can have some clues of what we're going to deal with regarding obsolete but still used browsers/platforms.

[Lars Richter]

That looks pretty cool. I did not know about Intl.NumberFormat. Thanks a lot for this informative post. 👍

[Mateusz Kwiatkowski]

It's so awesome! Thanks for the article :)

[mrwolferinc]

Thank you! Your tip is very helpful.

[Jean Pierre Chreim]

Thanks for this amazing information and API. Keep up the hard work 🔥 👏

[scroung720]

Oh my gosh. I almost cry hahahaha this is so good. I have spent months of my life writing code to solve multiple problems related to number rounding.

[Andrew Baisden]

Nice article :)

[Joseph Maurer]

Hey Jordan, Awesome post! I deal with having to format stuff like this all of time at work so I'm going to give Intl.NumberFormat a try. Thanks for the tip 👍🏻

[ChristophHeinemann]

give the .toLocaleString function a chance... it's Intl shortkey