Web Crypto API Algorithms Reference

Web Crypto API algorithm identifiers

The crypto.subtle interface takes a named algorithm for every operation, and each algorithm only supports certain operations. This reference lists the SubtleCrypto algorithm identifiers with a support matrix across sign, verify, encrypt, decrypt, digest, derive and wrap, plus a live filter.

How it works

Every SubtleCrypto call names an algorithm and supplies its parameters:

const sig = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,
  data
);

const ct = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  key,
  plaintext
);

An algorithm only works for the operations it supports — AES-GCM does encrypt/decrypt/wrapKey/unwrapKey but not sign; ECDSA does sign/verify but not encrypt. The matrix below maps each name to its valid operations.

Choosing the right algorithm for your task

The most common source of confusion with the Web Crypto API is picking an algorithm that does not support the operation you need. Here is a practical starting point for the most frequent use cases:

Symmetric encryption: Use AES-GCM. It is an authenticated encryption scheme — it encrypts the data and produces an authentication tag that detects tampering, so you do not need a separate HMAC. The iv (initialisation vector) must be unique for every encryption under the same key; 12 bytes generated with crypto.getRandomValues is the recommended practice. AES-CBC is available but requires you to add authentication separately, which is error-prone.

Asymmetric encryption: Use RSA-OAEP with at least a 2048-bit modulus length and SHA-256 as the hash. RSA-OAEP is the modern, secure padding mode; RSA-PKCS1-v1_5 encryption is legacy and should not be used in new code.

Digital signatures: ECDSA (Elliptic Curve DSA) with P-256 and SHA-256 is the modern recommendation — compact keys and signatures, widely supported, fast. RSA-PSS is a strong alternative if RSA keys are required. RSASSA-PKCS1-v1_5 (the older RSA signature scheme) is still supported but RSA-PSS is preferred for new systems.

Message authentication: HMAC with SHA-256 is the standard choice for symmetric message authentication — verifying that a message came from a known sender and was not modified. It is faster than asymmetric signing for high-volume scenarios.

Password-based key derivation: PBKDF2 derives a cryptographic key from a password with a salt and an iteration count. Use a high iteration count (at minimum tens of thousands; more is better for offline-attack resistance) and a 16-byte random salt per password. HKDF is for deriving one or more keys from an existing high-entropy secret, not from a user-supplied password.

Hashing: Use crypto.subtle.digest with "SHA-256", "SHA-384", or "SHA-512". These are exposed via the digest operation, not via sign. SHA-1 is still technically available via digest but must not be used where collision resistance matters.

Key import and export

Before using an algorithm, you often need to import a key — for example, from a base64-encoded server public key, a PEM, or raw bytes. crypto.subtle.importKey takes a format ("raw", "pkcs8", "spki", "jwk"), the key material, the algorithm object, an extractable flag, and a keyUsages array that must exactly match the operations you intend to call. A mismatch in keyUsages — for example, importing with ["encrypt"] but calling wrapKey — will throw a DOMException.

Tips and notes

• Prefer AES-GCM (authenticated) over AES-CBC for new code, with a unique IV.
• PBKDF2/HKDF/ECDH produce key material via deriveBits/deriveKey only — they cannot be used directly with encrypt or sign.
• Hash names (SHA-256, SHA-384, SHA-512) are used with digest and as the hash parameter inside signing/derivation algorithm objects.
• SHA-1 is supported for digest only and must not be used for signatures or HMAC in new systems.
• All SubtleCrypto methods return Promises and the data parameters expect ArrayBuffer or TypedArray, not strings. Convert with TextEncoder / TextDecoder as needed.