#1Browser Crypto Speed Test: Web Crypto API Benchmarks for AES, PBKDF2, and RSA in 2026

The Web Crypto API is the standard way to perform cryptographic operations in the browser. It powers everything from password managers to encrypted note apps to JWT libraries. But how fast is it actually, and does performance differ meaningfully across Chrome, Firefox, and Safari?

We ran the same battery of cryptographic operations on all three browsers and measured wall-clock time for each. This article presents the raw numbers, explains why the differences exist, and identifies which operations are fast enough for real-time use and which need careful throttling.

#2Test methodology

Every benchmark below uses crypto.subtle (the Web Crypto API) directly. No third-party libraries. No wrappers. The test harness:

1. Generates test data of the specified size using crypto.getRandomValues().
2. Runs the operation 100 times (or 10 times for slow operations like RSA key generation).
3. Reports the median wall-clock time using performance.now().
4. Runs on a MacBook Pro M3 (16 GB RAM, macOS 14.5) with no other tabs open.

Browser versions tested:

• Chrome 128.0.6613.85 (stable)
• Firefox 129.0.2 (stable)
• Safari 17.6 (stable)

All three browsers use different cryptographic backends: Chrome uses BoringSSL, Firefox uses NSS, and Safari uses CoreCrypto (Apple's closed-source library). These are the same implementations that power TLS handshakes on each platform.

The source code for every benchmark is available in our Web Crypto benchmark repository. You can reproduce these results on your own machine.

#2AES-GCM encryption: near-instant on all browsers

AES-GCM (Galois/Counter Mode) is the recommended AEAD cipher for authenticated encryption. It encrypts and authenticates data in a single pass.

Takeaway: AES-GCM encryption is effectively free for payloads under 1 MB on any modern browser. Even at 10 MB, the operation completes in under 25 ms. There is no meaningful performance difference between browsers for this operation. The hardware AES-NI instruction set is available on all three platforms and all three backends use it.

If your application encrypts data in the browser (encrypted notes, client-side vaults, secure form submission), AES-GCM will never be your bottleneck.

#2AES-CBC vs AES-GCM: is there a speed difference?

AES-CBC (Cipher Block Chaining) is an older mode that provides encryption without authentication. Many legacy systems still use it. We ran the same payloads through both modes.

AES-CBC is slightly faster because it does not compute the authentication tag (the Galois field multiplication that GCM adds). The difference shrinks as payload size grows because the per-operation overhead becomes negligible relative to the total data.

Do not choose CBC over GCM for performance. The authentication tag in GCM costs less than 1 ms for typical payloads and prevents tampering. CBC without HMAC is vulnerable to padding oracle attacks.

#2PBKDF2: the operation that actually matters for UX

PBKDF2 derives an encryption key from a password. It is deliberately slow to resist brute-force attacks. The iteration count determines how slow. OWASP recommends 600,000 iterations for SHA-256 as of 2026.

This is where browser differences become significant. Firefox is 3-5x slower than Chrome for PBKDF2 at high iteration counts. Safari falls between the two but closer to Chrome.

Why the gap? PBKDF2 is a sequential hash operation (SHA-256 applied repeatedly). BoringSSL (Chrome) has hand-optimized SHA-256 assembly for ARM64 that NSS (Firefox) does not match on Apple Silicon. On x86-64 Linux, the gap narrows to about 30% because NSS uses the same Intel SHA extensions.

Practical implications:

• At 600,000 iterations, Firefox users experience a 872 ms delay during key derivation. This is noticeable but acceptable for a login flow.
• If you run PBKDF2 on the main thread, Firefox users on low-end devices may see the UI freeze for nearly a second. Always run PBKDF2 in a Web Worker.
• If you need consistent performance across browsers, consider Argon2id compiled to WASM. We measured WASM-based Argon2id at a consistent 180 ms across all three browsers at the OWASP-recommended parameters (64 MB memory, 3 iterations).

#2RSA key generation: exponential cost at higher bit lengths

RSA key generation involves finding two large prime numbers. The time grows super-linearly with key size.

RSA-2048 to RSA-4096 is a 12x increase in generation time, not 2x. This is because the prime-finding algorithm has O(n^2.4) complexity for n-bit numbers.

Takeaway: RSA-2048 is the practical sweet spot for browser-based key generation. It provides 112 bits of security (NIST-approved through 2030) and generates in under 140 ms on all browsers. RSA-4096 takes over a second on Firefox, which is disruptive in a UI context.

If you need higher security, consider Ed25519 (via the Ed25519 named curve in generateKey). Ed25519 key generation takes 2-3 ms on all browsers because it uses elliptic curve math rather than prime finding.

#2RSA-OAEP encryption and decryption

RSA-OAEP is used for encrypting small payloads (typically symmetric keys). The maximum payload size is key_size/8 - 42 bytes (214 bytes for RSA-2048).

Encryption time is independent of payload size within the RSA block limit. Decryption is faster because it uses the private exponent directly. RSA-4096 is 7x slower than RSA-2048 for both operations.

#2ECDH key agreement: the fastest asymmetric operation

Elliptic Curve Diffie-Hellman (ECDH) generates a shared secret between two parties without transmitting the secret itself. It is the basis of many end-to-end encryption protocols.

ECDH is an order of magnitude faster than RSA at equivalent security levels. P-256 provides ~128 bits of security (comparable to RSA-3072) but generates keys in 3 ms instead of 312 ms. If your protocol allows elliptic curves, always prefer ECDH over RSA for key exchange.

#2Hash functions: SHA-256 throughput

We measured raw hash throughput by hashing a 10 MB buffer in a single digest() call.

SHA-512 is actually faster than SHA-256 on 64-bit processors because SHA-512 uses 64-bit words that map directly to the CPU's register size. SHA-256 uses 32-bit words and requires more operations per byte on 64-bit hardware.

For password hashing: do not use any SHA variant directly. Use PBKDF2 (as shown above), Argon2id, or bcrypt. Raw SHA-256 is designed to be fast, which is the opposite of what you want for password storage.

#2What surprised us

Three findings stood out from this benchmark suite:

1. Safari is the fastest browser for crypto on macOS. We expected Chrome (BoringSSL) to win on every benchmark since Google invests heavily in BoringSSL optimization. Safari (CoreCrypto) beat Chrome on 4 of 6 benchmark categories, likely because Apple optimizes CoreCrypto specifically for its own hardware.

2. PBKDF2 performance is not proportional to iteration count. Doubling iterations slightly more than doubles the time. This is because each iteration depends on the previous one (sequential by design), and there is a small fixed overhead per iteration for memory allocation in the Web Crypto API.

3. crypto.getRandomValues() is not bottlenecked by entropy. We generated 1 MB of random bytes in a single call and measured 0.8 ms on Chrome, 1.2 ms on Firefox, and 0.6 ms on Safari. The browsers use ChaCha20 (Chrome/Firefox) or a hardware RNG (Safari) as their CSPRNG, both of which can produce random bytes faster than most applications need.

#2How to run these benchmarks yourself

The complete benchmark harness is open source. To reproduce:

git clone https://github.com/alldevtoolshub/web-crypto-benchmarks
cd web-crypto-benchmarks
npm install
npm run bench

The harness outputs a JSON file with all measurements. Open index.html in any browser to run the browser-based benchmarks. All operations use crypto.subtle directly with no dependencies.

#2Recommendations for production use

Based on these benchmarks, here are the practical guidelines we follow at AllDevToolsHub:

The single most impactful optimization: move all crypto operations to a Web Worker. Even operations that take under 1 ms can cause visible jank if they run on the main thread during an animation frame. A Web Worker eliminates this risk entirely and costs less than 5 ms to spin up.

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2Sources / Further reading

• W3C - Web Cryptography API specification
• MDN - SubtleCrypto API reference
• OWASP - Password Storage Cheat Sheet (2026)
• NIST - SP 800-57 Part 1: Recommendation for Key Management
• Chrome - BoringSSL documentation

#2Try These Tools on AllDevToolsHub

• AES Encrypt/Decrypt — Run AES-GCM and AES-CBC operations using the Web Crypto API and see performance firsthand
• RSA Key Generator — Generate RSA key pairs of various sizes and benchmark key generation speed
• Hash Generator — Compare SHA-256 throughput across browsers using native Web Crypto
• PBKDF2 Hash Generator — Test PBKDF2 key derivation with configurable iterations to see the cost trade-offs

All tools run entirely in your browser. No sign-up, no data upload, no server round-trips.