Is the npm he Package Safe to Use? A Security Review

The npm he package is safe to use and is one of the most trusted HTML entity encoder/decoders in the JavaScript ecosystem, with no runtime dependencies and no known vulnerabilities in its current release. Written by Mathias Bynens, he (short for "HTML entities") encodes and decodes named and numeric character references exactly the way a browser would, including tricky astral Unicode symbols and ambiguous ampersands. If you have ever needed to turn < into < or decode 𝌆 back into a character, this is the library that does it correctly. The real question is not whether the package itself is safe, but whether you are using it for the job it was designed to do.

What the he package actually does

he exposes two core functions plus a couple of variants. he.encode() takes a string and replaces non-ASCII symbols and the characters &, <, >, ", ', and ` with character references. he.decode() reverses the process, turning both named references like © and numeric ones like © back into their characters.

const he = require('he');

he.encode('foo © bar ≠ baz 𝌆 qux');
// → 'foo © bar ≠ baz 𝌆 qux'

he.decode('foo © bar ≠ baz 𝌆 qux');
// → 'foo © bar ≠ baz 𝌆 qux'

It supports every standardized named character reference in the HTML spec, handles malformed input the way real browsers do, and ships with an extensive test suite. It has zero production dependencies, which is a meaningful security property on its own: fewer transitive packages means a smaller attack surface and fewer things to audit.

Is npm he actively maintained?

Yes. The library reached version 1.2.0 and remains stable and widely depended upon. It is one of those small, "done" packages — the HTML entity spec does not change often, so a low commit frequency here is a sign of maturity rather than abandonment. That distinction matters. For a fast-moving framework, a year of silence is a red flag; for a spec-complete utility like this, it is expected. Always judge maintenance status against what the package does, not against a raw commits-per-month metric.

You can confirm the version and integrity of what you are installing:

npm view he version
npm install he

Because he has no dependencies, the audit surface is just the package itself, which keeps npm audit output clean and makes supply-chain review trivial.

The real risk is misuse, not the package

Here is where teams get into trouble. he is a general-purpose HTML entity encoder. It is not a context-aware output-encoding library, and it is not an HTML sanitizer. Confusing those roles is how XSS bugs slip through even when you dutifully call he.encode().

Encoding for HTML text content is not the same as encoding for an HTML attribute, a URL, a JavaScript string, or a CSS value. Consider this:

// Encoding user input, then dropping it into an attribute WITHOUT quotes
const html = '<img src=x onerror=alert(1)>';
element.innerHTML = '<div class=' + he.encode(html) + '>';

he.encode() will escape the angle brackets, but if the surrounding markup uses an unquoted attribute, an attacker can still break out with characters that he does not treat as special in that context. The encoder did its job. The context was wrong. Output encoding must match the exact sink where the data lands, and a single HTML-text encoder cannot cover every sink.

Two rules keep you safe:

1. Use the framework's context-aware escaping (React's JSX, Angular's interpolation, or a templating engine's autoescape) as your primary XSS defense. These pick the right encoding per context automatically.
2. Reserve he for what it is good at: encoding or decoding entity references in text you control, such as generating static HTML, normalizing user-visible strings, or round-tripping content through storage.

If you need to accept and render rich HTML from users, you want a sanitizer such as sanitize-html or DOMPurify, not an entity encoder. Sanitizers strip dangerous tags and attributes; he only translates characters.

How to vet he (or any small npm dependency)

Even a well-regarded package deserves a quick supply-chain check before it enters your build:

• Pin the version in your lockfile and enable integrity hashes so a compromised republish cannot silently swap the code.
• Run npm audit and cross-check against a dedicated scanner — a software composition analysis tool catches advisories and transitive issues that npm audit sometimes misses, and flags typosquats of popular names.
• Watch for typosquatting. he is a two-letter name, and short names attract impostor packages. Confirm the author (mathiasbynens) and the repository before installing.

For a broader look at judging dependency health, the Safeguard Academy has a guide on evaluating open-source risk beyond the version number.

Bottom line

he is a small, focused, well-tested library that does exactly one thing correctly. It carries no known vulnerabilities and no dependency baggage. The security responsibility sits with you: use it for entity encoding and decoding, not as a substitute for context-aware output escaping or HTML sanitization. Get that boundary right and npm he is a safe, boring, dependable choice — which, for a security-relevant utility, is the highest compliment.

FAQ

Is the npm he package vulnerable to any known CVEs?

The current he release (1.2.0) has no known published vulnerabilities and no runtime dependencies, which keeps its attack surface minimal. Always re-check with an SCA scan or npm audit at install time, since advisory data changes.

Does he prevent XSS on its own?

Not by itself. he encodes HTML entities for text content, but XSS prevention requires context-aware encoding matched to where the data is inserted (attribute, URL, script, CSS). Rely on your framework's autoescaping and use a sanitizer for untrusted HTML.

Is he abandoned because it rarely gets updates?

No. he implements a stable specification, so infrequent commits reflect maturity, not neglect. Judge maintenance status by whether the package still does its job correctly, not by commit frequency alone.

Should I use he or a sanitizer like DOMPurify?

Use he to encode or decode entity references in text. Use a sanitizer such as DOMPurify or sanitize-html when you must render untrusted HTML markup and strip dangerous elements. They solve different problems.