We're happy to share that Ed25519 is now supported in Chrome (version). Following Ed25519 support in Firefox 129 (opens new window) in August 2024 and Safari 17.0 (opens new window), Chrome finally following suit in 137 in May of this year. Ed25519 is now supported in every major browser engine, reaching 79% and counting (opens new window) of web users.
Ed25519 is a type of key, most known because it is the smallest and fastest commonly-available key for generating and verifying elliptic curve cryptography (opens new window) signatures. Digital signature algorithms let you prove that a piece of data was created by someone with a specific private key, without needing to reveal that key. They're essential for authenticating software updates, Git commits, cryptocurrency transactions, and, in distributed networks like IPFS, for authenticating peer identities and quickly establishing trust among peers.
# What Ed25519 in WebCrypto API means for developers
Why is Ed25519 support in browsers valuable? If you’re coming from traditional web development, you’re probably familiar with the common hashes (SHA-256) and key types (RSA) already there, which are “table stakes” (often even available through standard libraries) unless you have very niche cryptographic needs. Built-in support for Ed25519 represents a significant upgrade across the board, bringing Ed25519 into that category of “table stakes” which developers can stop worrying about and just take for granted.
The key advantages:
Smaller footprint: Ed25519 keys are just 32 bytes (256 bits), compared to 256+ bytes for equivalent RSA security. Signatures are 64 bytes versus 256+ for RSA.
Faster operations: Signature verification is roughly 10x faster than RSA and consistently faster than ECDSA. Signature generation is also faster.
Security by design: Ed25519 was built from the ground up to resist timing attacks, uses deterministic signatures (no random number generation that can go wrong), and provides roughly 128-bit security level — equivalent to a 3072-bit RSA key.
Simpler implementation: Unlike ECDSA, Ed25519 doesn't require developers to handle tricky parameters or worry about malleability attacks.
Ed25519 signatures keys have long been one of the top key types and signatures everywhere except the browser, used to power everyday connection protocols like SSH (remote terminal) and sFTP (file transfer) and PGP (encrypted email) and all kinds of things. But until now, if your web app needed to verify an Ed25519 signature (say, to validate a Git commit or authenticate with an SSH-based service), you had to bundle your own cryptography libraries, which can often be half the “weight” (download size) of your web app that uses Ed25519 signatures today!
Of course, Ed25519 signatures don’t just make it easier to support long-standing protocols, they also power lots of cutting-edge and forward-looking identity systems as well. For example, Radicle, an open-world/decentralized git community, uses EdDSA keys as usernames and requires all repositories to be signed by them (since almost all git tooling across languages defaults to an EdDSA key manager at the OS level).
Identity systems like Radicle aren’t the only beneficiaries of being able to produce or check signatures in the browser; most “local-first” software, and of course all software based on content-addressable data benefit as well. For example, many web3 applications and distributed systems generally use content-addressed envelopes and documents rather than flat, traditional authorization tokens. Two of these, UCANs and BeeHive (the local-first/CRDT variant of UCANs), both scale up CRDTs and distributed workflows by giving every process, container, and resource an EdDSA key, so that all these authorization documents can be quickly and cheaply checked at any trust-boundary, including in the end-user’s browser. Making a safe verifier or web-view on any of these systems just got days, maybe weeks faster to build, which results in smaller binaries so much smaller they can go more places as a result.
With Ed25519 now in WebCrypto, these operations become a simple browser API call — no external dependencies, no bundle bloat, and better performance.
That qualifier “lightweight” is the main contribution here (and a counterintuitively very consequential one) to the commons of an increasingly cryptographic web. Tomorrow’s web is increasingly going to accrue ambient verifiability (even for publishers that don’t pay the CDN tax!), and many other downstream efficiencies fall out from being able to link up EdDSA keys which are already ubiquitous everywhere else in the average end-user’s operating systems and platforms.
# The Journey from Wanting to Having
Most of the updates you’ll see on this blog are about making IPFS work better with today’s web. Recently, we wrote about enabling true peer-to-peer connections through the HTTPS-only web with AutoTLS (opens new window), and before that there was a steady stream (opens new window) of improvements from the IPFS Shipyard team, which make it easier to discover and distribute IPFS data smoothly over the web.
But sometimes, if you dream big enough and invest on a long enough time horizon, you can actually make the web work a little more like IPFS. In recent years, there’s been a broader movement towards a more hash-based, trustless web in the form of cryptography creeping into web standards as the reactive, edge-cached, CDN-enabled web shifts user expectations towards better and better UX. Intervening in this trend and putting up the funding to do the slow, relentless pushing in web standards plants the seeds of a web more aligned to IPFS Principles (opens new window).
# How the web standards are governed, practically
The web has, in fact, been worldwide since most of us can remember, and even those of us old enough to remember its pre-ubiquitous phase have trouble remember the chaos of web development in those days when each browser took a blasé approach to HTML interoperability and how the details of HTTPS and TCP/IP were to be configured stably. Standardizing the web was almost as long and complex a technosocial process as making it worldwide or making it profitable, and it involved a lot of snarking on mailing lists, long before GitHub threads and Slack servers opened up new snarking surfaces.
The iterating and fine-tuning of software standards to a point where multiple completely-independent browsers could provably be uniform in how they render a given chaotic markup language (to say nothing of JavaScript!) is an ongoing and massive infrastructural accomplishment that battles on to this day. The janitorial work is led by a global-ish community, with lots of volunteers, underpaid experts, and tired academics providing extra patience and human-power. Their devotion keeps the web a durable and open platform for information, which could revert to mere plumbing for commerce if left entirely to large commercial players.
When you think about web standards, people naturally think about the Big Decisions and governance quagmires around specific technologies: how JavaScript can be sandboxed and policy-bound to safely run across domains, how CSS can get inherited and nuanced and last-mile exceptioned as it cascades over those same domains, etc. Smaller languages, thin protocols that run over the web (federated identity, social web, payments), accessibility and localization standards, and Big Semantics round out the rest of what we call “web standards,” mostly standardized at the World Wide Web Consortium (W3C) with the regular collaboration from adjacent standards development organizations.
Historically, most debate and standardization around cryptography happened one level below the web at IETF (opens new window): as a rule of thumb, you could say “the web” is for humans and their messy semantics, while “the internet” is a superset powered by machines who can standardize on the stuff that vanishingly few humans even understand. But increasingly, to make the web more secure (think: passkeys, FIDO, wallets) web standards increasingly need cryptographical ground-truths in common web-wide as well. These have made one of the most closely-watched groups at the W3C the “WebCrypto API”-- where browser developers agree to interfaces that build basic cryptographic building blocks into the browser itself, incentivizing reuse and transparency by offloading crypto complexity onto the “web platform” itself (the ground assumptions about how the whole web will work in any browser).
The WebCrypto interface gives all web developers a powerful take-out window to order reliable and determinic signatures and hashes from, which enables all kinds of powerful building blocks in a few lines of code. For instance, the increasingly generalized SubResource Integrity (opens new window) pattern allows many of the heaviest parts of web development (big media files, JavaScript bundles that change often due to security and dependency trees) to be “checksummed”, i.e. integrity-protected by a hash. This dovetails nicely with the generalized integrity-protection that IPFS brings to web development; speeding up the browsers’ support for more sub-resource integrity mechanisms also makes the web much more IPFS-ready and makes IPFS more intuitive to tomorrow’s web developers.
# Igalia, Standards Work and Actual Adoption
So how exactly did IPFS support directly bring about Ed25519 becoming a browser default? The answer involves a three-year collaboration with Igalia (opens new window), a worker-owned open source consultancy and co-operative that has become a major contributor to browser development since 2001.
It’s hard to overstate just how much work goes into even a comparatively simple web platform feature such as this one. If you want a peek at what happens behind the curtain, I strongly recommend Javi’ blog post from February 2025 summarizing the progress to date (opens new window).
The specific focus of this collaboration was getting Ed25519 “into the browser” by default, with an eye to tools like Verified Fetch (opens new window). Verified Fetch not only fetches content from IPFS by CID like any other client, but crucially it also verifies that each block matches its CID. Since Verified Fetch needs to be able to install as close to “invisibly” as possible, it is a huge UX improvement to reduce its download size by a two-digit percentage, which is achieved by outsourcing the math and the logic to the browser’s built-in library.
A PR on a browser engine is significantly more complex than a typical open source contribution. It requires extensive coordination across implementations, specifications, security review processes, performance review processes, quality assurance, and more. Javier (“Javi”) Fernandez at Igalia drove PRs (opens new window) against all three of the major independent browser engines in parallel, juggling change requests and nits and corner-cases to make sure all three would handle any inputs the exact same way under any configuration or combination of extensions.
The work began with identifying and fixing a bug (opens new window) in the W3C specification governing the WebCrypto interface. Over three years, Javi systematically addressed technical challenges in 3 browsers’ codebases, from low-level C implementations to API surface design.
# What’s Next
Ed25519 support went live in May 2025 Chrome 137 (opens new window), joining every other major browser before it.
Typically, it takes 2-3 years for new browser versions to proliferate across the user landscape. We anticipate that around 2027, developers can confidently start relying on simple and stable support for Ed25519 in most users’ browsers.
As this transition happens, developers can drop weight from our software packages, complexity from testing and maintenance, and load-time and bandwidth. In aggregate, that makes the web a lot more powerful for everyone, and more aligned with the IPFS principles: simple, modular, and verifiable. It’s a rare case of everybody winning, and the entire web getting a little more stable and good.
Thanks to Protocol Labs (who initiated the collaboration with Igalia), the IPFS Foundation, Open Impact Foundation (opens new window), and WebTransitions.org (opens new window) for continuing to shepherd this initiative.
More IPFS initiatives and collaborations to make the web more simple, modular, and verifiable are in progress. They include ElectronJS build variants (opens new window) (to support better protocol handling), more useful protocol handling in browser extensions (opens new window) (webtransitions theme (opens new window)), as well (we hope) streaming support in browser cryptography APIs!