# ethers.js: the TypeScript Ethereum library, and what v6 changed for people upgrading from v5

> A complete JavaScript and TypeScript library for wallets, contracts and providers, MIT licensed including all dependencies. Version 6 is a rewrite with a different provider and ABI API.

**ethers-io/ethers.js** — Complete Ethereum library and wallet implementation in JavaScript.

- Repository: https://github.com/ethers-io/ethers.js
- Website: https://ethers.org/
- Stars: 8,717 · Forks: 2,131
- Language: TypeScript
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/ethers-io-ethers-js

## One package for keys, contracts, RPC and ENS

The README positions ethers as a complete, compact and simple library for Ethereum, written in TypeScript. The feature list is the honest description of scope: private key handling in the client, JSON wallet import and export for Geth, Parity and crowdsale formats, BIP 39 mnemonic phrases and HD wallets in eight languages, meta-classes that build JavaScript objects from any contract ABI including ABIv2 and the human-readable ABI, connection to nodes over JSON-RPC, and ENS names usable anywhere an address can be used.

That last point is worth pausing on. ENS being first-class rather than bolted on means a function typed to accept an address also accepts a name. In a codebase with a dozen places that take an address, that removes a conversion layer.

Two build claims are concrete enough to check. The compressed bundle is around 144kb and the uncompressed around 460kb, and the build is tree-shaking focused so a bundler includes only what you import. The `exports` map in `package.json` exposes subpath entry points beyond the root, so `ethers/abi` and `ethers/address` can be imported individually rather than pulling the whole library.

The repository tree backs up the build story: `src.ts/` for sources, `dist/` for the browser bundle, separate `lib.esm/` and `lib.commonjs/` output directories, four separate tsconfig files for types, ESM and CommonJS, and a rollup config. Node 14 or newer is the stated engine requirement.

## Installing from npm, or loading the browser bundle directly

For a Node project the install is unremarkable:

```bash
npm install ethers
```

For a browser without a bundler, the built bundle lives in the `dist/` folder of the repository and is loaded as an ES module:

```html
<script type="module">
    import { ethers } from "./dist/ethers.min.js";
</script>
```

The dependency list in `package.json` is short, and that is the point of the tree-shaking claim. Runtime dependencies are `@adraffy/ens-normalize` for ENS name normalisation, `@noble/curves` and `@noble/hashes` for elliptic curve and hash primitives, `aes-js` for the legacy AES path, `ws` for WebSocket providers, `tslib`, and `@types/node`.

Depending on the noble packages for elliptic curve and hash primitives rather than bundling a native crypto library is the decision that matters most in a wallet library, because the cryptography here is doing key derivation and signature work. The MIT licence covering all dependencies means you do not need to check licence compatibility across that tree separately.

Development tooling is the conventional TypeScript and Rollup stack: TypeScript 5, Rollup with the node-resolve plugin, mocha with c8 for coverage, uglify-js for minification and semver.

## Shared provider keys are throttled on purpose

The Providers section describes a design decision that surprises people. Ethers ships with default API keys for a growing list of third-party services, so `ethers.getDefaultProvider()` works immediately with no signup. The keys are shared, and the README is explicit that they are intentionally throttled to push developers toward getting their own.

The services credited with providing community resources are Ankr, QuickNode, Etherscan, Infura and Alchemy. The connection support listed earlier in the features list also names MetaMask as a target, which is a browser wallet rather than an RPC endpoint.

What you lose by staying on shared keys is spelled out: faster responses, more capacity, analytics, and features like archival data. Archival data is the one that bites hardest, because a node that only keeps recent state cannot answer historical calls, and anyone building an indexer or a backtest will hit that wall without warning.

The signing-up path is documented under provider API keys, and the README points there rather than describing it inline. For a project that will see real traffic, the shared key is a development convenience with a documented expiry in usefulness.

## Extension packages for what the core deliberately leaves out

The README states plainly that the `ethers` package only includes the most common and most core functionality, then lists the extensions. This is a useful admission, because the missing pieces are exactly the ones that distinguish a production integration from a demo.

Five are named. `MulticallProvider` bundles multiple call requests into a single `call` to reduce latency and backend request capacity, which is the standard answer to slow dashboards that make one request per row. `MulticoinPlugin` is a provider plugin expanding ENS coin type support. `GanaceProvider`, named for Ganache, is a provider for in-memory node instances for fast debugging, testing and simulating operations. There is an Optimism utilities collection and a `LedgerSigner` for talking directly to Ledger hardware wallets.

Read together, that list tells you what the core does not do. It does not batch, it does not simulate, it does not sign through hardware wallets, and it does not carry L2-specific helpers. The `GanaceProvider` entry is the one to note for testing: an in-memory node means your test suite does not need a chain, and the distinction between that and mocking the provider is meaningful for confidence.

If you need EIP-1193 style wallet injection outside MetaMask, or a signer from a hardware device other than Ledger, you are assembling that from extension packages rather than from the core.

## Version 6 is a rewrite, and the release notes show the edges

The documentation links point at the v6 docs, and the repository is on v6. The visible releases show what that version line has been doing. v6.17.0 on 2026-06-18 added a requestRate throttle to calls and provider requestRate throttle support. v6.16.0 on 2025-12-03 added a utility method to split EIP-7594 blob proofs into their cells and updated the Alchemy mainnet URL endpoint. v6.15.0 on 2025-07-02 allowed non-canonical S values in signatures and moved the resulting errors to access time.

That v6.15.0 change is instructive. Accepting non-canonical signature values and deferring the error until access rather than throwing immediately is the kind of accommodation needed when the network accepts something the spec library considers non-standard. It also means a signature that once threw at parse time may now surface later, which changes where your error handling has to live.

The blob work in v6.16.0 points at the direction of travel: blob proofs and cell splitting are data-availability machinery that arrives with increasing traffic and increasing per-block data, and the library is adding primitives to handle it rather than leaving it to the caller.

The README keeps a list of monthly or near-monthly summary posts going back to December 2020, which is the best available guide to how a large API surface changes over time. The CHANGELOG is linked separately for detail.

## Security practice, licensing, and where the README is thin

The README has a short section on keeping updated, and it is the part a security reviewer should read first. Advisories and important notices go out through the project's Twitter account, described as low-traffic and non-marketing, plus watching the GitHub repository. General news and discussion go through the maintainer's account and the project Discord.

There is a `SECURITY.md` in the repository and a `FUNDING.json`, plus a GitPOAP badge. The funding address in the package metadata is an ENS name, `donations.ethers.eth`, which is a small illustration of the library's own features being used for its own infrastructure.

Licensing is the cleanest part of the story: MIT, and the README emphasises that this includes all dependencies. That is worth contrasting with wallet libraries that pull in transitive dependencies under copyleft or dual licences, because it removes a class of question from your legal review.

Where the README is thin is everything about operational safety. It does not document how to handle a mnemonic in a browser, whether the bundled browser build is appropriate for holding keys, or what to do when a provider key leaks. The docs site covers more, and the tree contains a `testcases/` directory described as a large maintained collection of test cases, which is where you would look to see how the library behaves on known vectors rather than on the marketing summary.

## Conclusion

ethers.js is a good fit when you want one library covering key handling, ABI encoding, JSON-RPC, ENS and contract calls, and you want it written in TypeScript with a tree-shakeable build rather than a bundle of dependencies. The costs are honest ones: the v5 to v6 migration touches the provider and ABI surface, the wallet and mnemonic handling puts real key material in your process, and the shared default provider keys are throttled on purpose. Start from `docs.ethers.org/v6/getting-started/` rather than an old tutorial, and pin the major version in your package manifest because v5 examples online are common and mostly wrong for v6. The last push was on 2026-06-18 and v6.17.0 was published the same day, adding a provider request rate throttle. The MIT licence extends to all dependencies, which removes a question you have to ask with most wallet libraries.

## FAQ

### What is ethers.js and who is it for?

It is a complete Ethereum library written in TypeScript, covering private key and JSON wallet handling, BIP 39 mnemonics and HD wallets, contract ABI decoding, JSON-RPC providers and ENS names. It is MIT licensed including all dependencies, and the build is tree-shaking focused so bundlers include only what you import.

### How do I install ethers.js and load it in a browser without a bundler?

For Node, install the package with `npm install ethers`. For a browser, the built bundle in the repository's `dist/` folder is imported as an ES module, for example `import { ethers } from "./dist/ethers.min.js"` inside a script tag with `type="module"`. Node 14 or newer is required.

### Does ethers.js work with free API keys from Infura or Alchemy?

Yes, and the README says so directly. Ethers ships shared default keys so `ethers.getDefaultProvider()` works with no signup, and those keys are intentionally throttled. Getting your own keys unlocks faster responses, more capacity, analytics and archival data, which shared keys do not provide.

### What is missing from the core ethers package?

The README says the core package covers only the most common functionality, and lists extensions for the rest: MulticallProvider for batching calls, MulticoinPlugin for extra ENS coin types, a Ganache provider for in-memory test nodes, Optimism utilities, and a LedgerSigner for hardware wallets.

### What license does ethers.js use?

MIT, and the README states the licence covers all dependencies as well, which is unusual for a library with a cryptographic dependency tree. Runtime dependencies include the noble curves and noble hashes packages for elliptic curve and hash work.

## Sources

- [ethers-io/ethers.js on GitHub](https://github.com/ethers-io/ethers.js)
- [License: MIT](https://github.com/ethers-io/ethers.js/blob/main/LICENSE)
- [Project website](https://ethers.org/)
- [README](https://github.com/ethers-io/ethers.js/blob/main/README.md)
- [Releases](https://github.com/ethers-io/ethers.js/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ethers-io-ethers-js