NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
npm · #5109 most downloaded on npm
Various operations on Uint8Array data
Last release 21 days ago
22 Sep 2026
Release timing varies
gaps range from 8 days to 4 months
Most releases are documented
notes for 12 of 20 stable releases
Nothing withdrawn
no release was ever pulled
1 years old
33 releases · first in 2025
One column per month.
Added import { crc32 } from '@exodus/bytes/crc.js' .
Added import { crc32 } from '@exodus/bytes/crc.js'.
It's fast.
Native under "node" import condition, polyfilled everywhere else.
Full Changelog: v1.15.2...v1.16.0
fix: fromHex on Node.js validation in 47fc52c
Full Changelog: v1.15.1...v1.15.2
This fixes a bug in fromHex validation behavior on Node.js 24.x and below.
Affected are platforms resolving to "node" import condition that do not have native Uint8Array.fromHex.
"node" import conditions are not affected.On affected platforms, fromHex failed to reject some invalid strings:
% node
Welcome to Node.js v24.21.0.
Type ".help" for more information.
> require('@exodus/bytes/hex.js').fromHex('\u0041\u0042') // correct, this is 'AB'
Uint8Array(1) [ 171 ]
> require('@exodus/bytes/hex.js').fromHex('\u0141\uFF42') // incorrect, high byte in input symbols is coerced
Uint8Array(1) [ 171 ]This is now fixed.
fix: don't use bigint literals by @exo-mv in #72
doc: deprecate latin1toString() / latin1fromString() in favor of isomorphicDecode() / isomorphicEncode() (see #55 )
isomorphicDecode(), isomorphicEncode() in /encoding.js (in #68)latin1toString() / latin1fromString() in favor of isomorphicDecode() / isomorphicEncode() (see #55)fromBase32crockford / toBase32crockford in /base32.jstypedCopyBytes() in /array.js'arraybuffer' output format support in methods accepting format parameter (in #70)'uint8' (default) output format now never returns pooled Uint8Array instances (see below)This release brings support of native ArrayBuffer return format (under the name of format: 'arraybuffer').
Converting Uint8Array to ArrayBuffer downstream is non-trivial, and there is a lot of confusion in the ecosystem around those.
A simple access to .buffer is often seen and is incorrect -- code accepting Uint8Arrays that it didn't create should not assume that it did not receive for example a result of .subarray() (where .buffer size mismatches the view size), or a Node.js pooled Buffer instance (which are also Uint8Arrays).
That pattern (using .buffer and failing to check bounds) has been a source of numerous errors in ecosystem libraries.
To minimize the risks from such mistakes, this library now never returns Uint8Array instances (default format) that are not complete views of their underlying ArrayBuffer.
In other words, now the following are true for a returned Uint8Array instance u8:
u8.buffer.byteLength === u8.byteLengthu8.byteOffset === 0deepStrictEqual(new Uint8Array(u8.buffer), u8)The affected parts (which previously returned non-complete views / subarrays) are:
fromBase58Check, createMultibyteEncoder, createSinglebyteEncoderlatin1fromString, utf8fromString, utf16fromStringfromHex, fromBase64This comes at a reasonable performance cost (almost exclusively on Node.js import condition), but correctness/security comes first.
Note
This change doesn't affect TextEncoder, which is already governed by the Encoding Standard which demands non-pooled Uint8Arrays.
This also doesn't affect typedView() (from /array.js) which by definition is always a view of the same underlying ArrayBuffer data.
But now typedCopyBytes() is introduced.
Important
This change does not affect 'buffer' return format, which can still return pooled Buffer instances.
This is similar to the behavior of native Buffer.from / Buffer.alloc which are pooled.
Apart from making returned Uint8Array instances complete views, a dedicated ArrayBuffer return format is introduced to eliminate the need to use .buffer on the returned values in downstream code at all (as it's a bad pattern in general and tooling/lint will/should flag that).
Full Changelog: v1.14.1...v1.15.0
fix: ensure TextEncoder never returns pooled arrays
fix: ensure TextEncoder never returns pooled arrays
Previous implementation always ensured 0-offset Uint8Array (ret.byteOffset === 0),
but not that there is no data past the returned view (ret.byteLength === ret.buffer.byteLength).
This is now fixed.
This only affected Node.js-like platforms, as only there native buffers are pooled.
Full Changelog: v1.14.0...v1.14.1
Fix makeBase58check() Typescript types
Fix makeBase58check() Typescript types
Add sideEffects configuration
Only @exodus/bytes/encoding.js export has side-effects, and those side-effects are internal:
It is documented to load multi-byte codecs for both this import and future (and previous) /encoding-lite.js imports, even if the current import does not use the provided TextDecoder.
Both /encoding.js and /encoding-lite.js are designed to return the exact same TextDecoder class and methods, and loading full implementation provides multi-byte encodings support everywhere.
As /encoding-lite.js can be used as a global polyfill, the setup has to avoid polyfill conflicts if something loads /encoding.js and then something else replaces it with /encoding-lite.js (or vice versa)
The same mechanism is reused to keep /whatwg.js minimal by default, and only support multi-byte encodings if /encoding.js was imported and loaded them at any point.
This is not a new change, just documenting the existing behavior and exposing sideEffects configuration so that bundlers can optmize out other imports.
Further bundle size optimizations
Full Changelog: v1.13.0...v1.14.0
Bundle size reductions, especially for browsers
Bundle size reductions, especially for browsers
Under browser module resolution target, we rely on browsers to have a working UTF-8 / UTF-16 / windows-1252 (latin1 subset) TextDecoder implementation that doesn't have bugs when used without streaming and with ignoreBOM: true, and a TextEncoder
While browsers have bugs even in UTF-8, those bugs are related to streams and/or BOM processing, and that specific combination we use seems to be always robust.
In previous versions we already used native codepaths for those where possible and operated under the same assumption.
Disable hex/base64 performance optimization for Firefox >=133 <146
We used a guarded useragent check for those versions to prefer js fallback instead of native base64 / hex implementations, as native was slow before FF 146 (ref: https://bugzilla.mozilla.org/show_bug.cgi?id=1994067 and linked issues)
As the usage of FF <146 diminished according to caniuse stats, this check is not worth it anymore.
This version removes that useragent check.
Those Firefox versions are still supported by the library, but now the native base64 / hex implementation is always used when available.
See 8cab29a for implementation details.
Full Changelog: v1.12.0...v1.13.0
Fix UTF-16 on platforms with present but broken native UTF-16 TextDecoder (e.g. workerd, see cloudflare/workerd#6028 )
Full Changelog: v1.11.0...v1.12.0
feat: add /whatwg.js and percentEncodeAfterEncoding() in #37
/whatwg.js and percentEncodeAfterEncoding() in #37utf16toStringLoose(Uint16Array) on Big-Endian hardware in #44Full Changelog: v1.10.0...v1.11.0
Add TypeScript types for all entry points
Uint8Array<SharedArrayBuffer> inputFull Changelog: v1.9.0...v1.10.0
Implement strict multi-byte encoders, except for iso-2022-jp for now
iso-2022-jp for now/encoding-browser.js to load only native lightweight TextDecoder/TextEncoder in browser bundles/index.js export with usage warning, mostly for IDEs/base58check.js peer dep (used on non-Node.js platforms) to @noble/hashes directly (previously @exodus/crypto)legacyHookDecode() behavior on non-even (incomplete) UTF-16 byte lengthutf16toString(uint16arr) on Big-Endian Node.jsFull Changelog: v1.8.0...v1.9.0
feat: support iso-8859-1 , iso-8859-9 , iso-8859-11 encodings in single-byte.js
iso-8859-1, iso-8859-9, iso-8859-11 encodings in single-byte.jslatin1fromString, latin1toStringencoding.js by @ajaymathur in #12encoding-lite.jsFull Changelog: v1.7.0...v1.8.0
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →