react-number-format is a well-maintained React library for formatting numbers, currencies, and masked inputs, and it has no known security vulnerabilities in its current release, but it is a formatting tool and not a validation or sanitization layer. Confusing those two roles is the most common way teams introduce a bug while using it.
This guide walks through what the npm react-number-format package does, its actual security posture, and the patterns that keep formatted inputs from becoming a weak point in your application.
What react-number-format Does
The react number format library renders input fields that automatically format their value as the user types: adding thousands separators, currency symbols, decimal precision, or fixed patterns like phone numbers and card numbers. It also supports a display mode for read-only formatted text.
import { NumericFormat, PatternFormat } from "react-number-format";
// Currency input
<NumericFormat
value={amount}
thousandSeparator=","
prefix="$"
decimalScale={2}
onValueChange={(values) => setAmount(values.floatValue)}
/>
// Masked pattern for a card number
<PatternFormat format="#### #### #### ####" value={card} />
The important detail for correctness is onValueChange, which hands you both the formatted string and the parsed numeric value. Using the parsed value, not the display string, for calculations and storage avoids a whole class of subtle bugs.
Security Posture: Genuinely Good
The honest assessment is reassuring. The current version of react-number-format has no known vulnerabilities, and the package is actively maintained with a healthy release cadence and millions of weekly downloads. It is not an abandoned dependency, and it does not carry outstanding advisories.
That said, "the library is safe" and "your usage is safe" are different claims. The risks with a formatting component are almost never in the component itself; they are in how the surrounding code treats the value.
Formatting Is Not Validation
This is the single most important point. react-number-format controls how a value looks, not whether it is acceptable. A field that displays $1,000.00 will happily accept and format a value your business rules should reject, such as a negative amount, a quantity above a limit, or a number with more precision than your backend stores.
// Formatting alone does not enforce business rules
<NumericFormat
value={amount}
isAllowed={(values) => {
const { floatValue } = values;
// Reject values outside the allowed range at input time
return floatValue === undefined || (floatValue >= 0 && floatValue <= 1_000_000);
}}
onValueChange={(values) => setAmount(values.floatValue)}
/>
The isAllowed prop gives you client-side gating, which improves the user experience, but it is not a security control on its own. Anyone can bypass the browser and post arbitrary values to your API. Every constraint that matters must be re-enforced server-side. Treat client formatting as convenience and server validation as the actual boundary.
Where XSS Could Sneak In
react-number-format renders through React, which escapes values by default, so the component itself does not introduce cross-site scripting. The danger appears when developers take a formatted value and render it through an unsafe path elsewhere.
The pattern to watch for is taking user-entered content, even a formatted number, and injecting it into the DOM directly:
// Dangerous: never route user-influenced content through dangerouslySetInnerHTML
<div dangerouslySetInnerHTML={{ __html: userProvidedLabel }} />
That risk has nothing to do with react-number-format specifically, but formatted-input fields often sit next to user-editable labels and descriptions, so it is worth stating plainly: keep everything inside React's normal escaping, and never hand user-influenced strings to dangerouslySetInnerHTML or an equivalent.
Keeping the Dependency Current
Even a clean package needs a maintenance plan, because its own dependencies and the ecosystem around it shift over time.
npm outdated react-number-format
npm audit
Because react-number-format is a direct UI dependency, upgrades are usually low-friction, but check the changelog for breaking changes between major versions, since the API was reorganized in the move to the 5.x line. For the broader picture of what your app pulls in transitively, an SCA scanner such as Safeguard resolves the full tree and flags any dependency, direct or indirect, that develops a known issue. Our SCA product covers how that continuous monitoring works so a package that is clean today does not silently become a liability later.
A Practical Checklist
When you add npm react-number-format to a form, confirm four things. Store the parsed numeric value, not the formatted string. Enforce ranges and precision with isAllowed for UX and again on the server for security. Keep all rendering inside React's default escaping. And add the package to your dependency-scanning coverage so future advisories reach you automatically.
Do those, and react-number-format is exactly what it should be: a small, reliable piece of your form layer rather than a source of risk.
FAQ
Does react-number-format have security vulnerabilities?
The current version has no known vulnerabilities and the package is actively maintained. The real risk lies in how your application handles the values, not in the library itself.
Is react-number-format's isAllowed prop a security control?
No. isAllowed gates input in the browser for a better user experience, but it can be bypassed by posting directly to your API. Always re-enforce the same rules server-side.
Should I store the formatted string or the numeric value?
Store the parsed numeric value that onValueChange provides, not the display string with separators and symbols. Storing formatted text leads to parsing bugs and inconsistent data.
Can react number format cause XSS?
Not on its own, because it renders through React's default escaping. XSS only appears if you take user-influenced content and render it through an unsafe path such as dangerouslySetInnerHTML, which you should avoid regardless.